If I use the “fire-and-forget” command dispatch API (the single-argument dispatch() method on a command bus) like the Axon docs recommend for maximum scalability, what reliability guarantees are there?
To be more specific, suppose the following happens:
- Incoming request arrives from client.
- Request handler dispatches some number of commands.
- Request handler returns a “request in progress” response to the client.
- The server gets restarted (e.g., due to hardware failure).
Will any unhandled commands be processed when the server comes back up, or will they be lost?
It seems like the answer is “they’ll be lost” because I don’t see any persistence mechanism for commands, nor any way to use something like AMQP for command delivery. (Events, on the other hand, do seem to provide better reliability guarantees.)
If I’m incorrect about that, can someone describe what the reliability mechanism is, or point me to the relevant section of the docs?
If I’m correct, does that mean that if I want to guarantee that any client request I acknowledge is actually processed by the server at some point, I need to avoid using the fire-and-forget API and instead have my client request handler wait for callbacks to be called on any outgoing commands before acknowledging a request to the client?
That seems like it effectively means my command handlers have to be synchronous, even if their completion is communicated back to the calling code via an async-friendly callback mechanism. Is that the right approach, or should I be doing something else?
Thanks!