I am designing a microservice architecture, using a database per service pattern.
Following the example of Order Service and Shipping Service, when a user makes an HTTP REST request to the Order Service, this one fires an event to notify shipping service. All this happens asynchronously. So, what happens with the user experience? I mean, the user needs an immediate response from the HTTP request. How can I handle this scenario?
All this happens asynchronously. So, What happen with the user experience? I mean, the user needs an immediately response from the HTTP request. How can I handle this scenario?
Respond as soon as you have stored the request.
Part of the point of microservices is that you have a system composed of independently deployable elements that do not require coordination.
If you want a system that is reliable even though the services don't have 100% uptime, then you need to have some form of durable message storage so that the sender and the receiver don't need to be running at the same time.
Therefore, your basic pattern for data from the outside is that the information from the incoming HTTP request is copied, not directly into a running service, but instead into the message store, to be processed by the service at some later time.
In other words, your REST API is a facade in front of your storage, not in front of the service itself.
The actor model may be a useful analogy; information moves around by copying messages into different inboxes, and are later consumed by the subscribing actor.
From the perspective of the client, the HTTP response is an acknowledgement that the request has been received and recognized as valid. Think "thank you for your order, we'll send you an email when your purchase is ready for pick up."
On the web, we would include in the response links to other useful resources; click here to see the status of your order, click there to see your history of recent orders, and so on.
Sagas are complex, but it is necessary to understand why they are used. Saga patterns are used to handle transactional problems between microservices. Think of the commit and rollback actions in a database. You would perform them locally. This behavior is remotely implemented by Sagas.
Following the pattern, for example, when the Order microservice triggers the OrderCreated event, the Inventory microservice will listen for OrderCreated and perform inventory operations. If all items are available, PreStockDone will be triggered, but if some are not, then UnauthorizedStock will be triggered. The Order microservice will listen to both events and update the order accordingly: continue with the order when PreStockDone, or cancel the order when UnauthorizedStock.
This means that events will happen at some point, but not immediately. Given this, your response to the user will always be the first step of the Saga. On the mentioned example, it would be the newly created order, regardless of the stock verification. In this case, you should inform the user, "Thank you for your purchase. We have received your order, and it will be processed soon!"
Remember, in data storage, transactions refer to the modifications applied to entities. Sagas are used only in this case.
Therefore, when you need a microservice to retrieve data from another microservice, you should establish synchronous communication. You can use the HTTP protocol, gRPC, or any other protocol.
In optimized systems, for example, it is common to have a dedicated database for queries (ElasticSearch, MongoDB, etc.). In this case, you would have a new microservice, such as OrderReports, which would receive all the data already formed from events and publish it in its own read database. And in this case, instead of reading orders directly in the Order microservice, you would read them directly in the OrderReports microservice.
