Say that an HTTP request comes in as the start of a logical series of events. For example, money is to be reserved from an account, to be eventually transferred elsewhere. The HTTP request expects a response, determined by whether we were able to reserve money and promise to eventually transfer it.
Now, the eventual stuff is likely to be processed in the background. It could use a SQL transport and not care about its polling delays. It enjoys the concurrency protection of sagas. All is good.
However, let’s consider the initial work. Let’s say that there is an existing saga that handles the account’s balance. As such, for us to provide a response to the HTTP request, that saga would need to handle a message.
It seems like a great waste (even more so with a SQL transport) to persist a message, have another endpoint instance pick it up after a delay (invoking the target saga), having it persist a reply, and then having the original HTTP request handler pick up the reply after another delay.
Instead, I would want the HTTP request handler to immediately handle the message that triggers the saga, i.e. not send it over any queue, but just instantiate and handle such a message instantaneously. This way, it can simply handle the HTTP request immediately, while stile benefitting from the concurrency protection of the saga.
Is this possible? Are there other ways to achieve a comparable effect?
(Note that it matters not if a failure occurs and the message is never handled: in the first step, we are still in HTTP territory. Even if we would persist and retry the input, the caller may already have experienced connection issues, with no clue of the result. The only guarantee that we can give with HTTP is that if the caller receives a success response, then we will [eventually] be consistent with our promise.)