A reactive microservice-based order management system

Let's examine another microservices example: an online retail web site. In this case, we will focus more on the backend services, such as the order event generated when the customer places an order through the website:

This microservices system is completely designed based on reactive programming practices.

When an event is published, a number of microservices are ready to kick start upon receiving the event. Each one of them is independent and is not relying on other microservices. The advantage of this model is that we can keep adding or replacing microservices to achieve specific needs.

In the preceding diagram, there are eight microservices shown. The following activities take place on arrival of an OrderEvent:

• OrderService kicks off when an OrderEvent is received. OrderService creates an order and saves details to its own database.
• If the order is successfully saved, an OrderSuccessfulEvent is created by OrderService and published.
• A series of actions will take place when OrderSuccessfulEvent arrives.
• DeliveryService accepts the event and places a DeliveryRecord to deliver the order to the customer. This in turn generates DeliveryEvent and publishes the event.
• The TruckingService picks up the DeliveryEvent and processes it. For instance, TruckingService creates a trucking plan.
• CustomerNotificationService sends a notification to the customer informing the customer that an order is placed.
• InventoryCacheService updates the inventory cache with the available product count.
• StockReorderService checks whether the stock limits are adequate and generates ReplenishEvent if required.
• CustomerPointsService recalculates the customer's loyalty points based on this purchase.
• CustomerAccountService updates the order history in the customer account.

In this approach, each service is responsible for only one function. Services accept and generate events. Each service is independent and is not aware of its neighborhoods. Hence, the neighborhood can organically grow as mentioned in the honeycomb analogy. New services could be added as and when necessary. Adding a new service does not impact any of the existing service.