Architecture between services

The importance of proper communication between microservices

Microservices should be able to work independently from each other. One system dropping out should not break the rest, the other services should stay working. This presents a challenge when services have to communicate with each other.

As an example, let's say a user wants to start an auction for an item they own. The client will first send a REST call to the inventory service in the backend to check if the user actually owns the item. This is done to prevent people from posting auctions of items they don't actually own. When the inventory system concludes that the player owns the item it will remove it and send a message to the auction service. If this auction service were to be down but the inventory service is still up and running the backend would remove the item from the players inventory and never actually start the auction. Of course this is a problem.

To fix this a message broker can be used. A message broker can hold messages in queues. When a service is ready it will take a message from the queue and process it, if it is successfully processed it will remove the message from the queue. In case it was not processed correctly it will still exist in the queue for a next attempt. This also means that messages will be stored if no services is available to take the messages. Because of this messages are assured to eventually reach their destination.

Now, using a message broker, when a user wants to start an auction the inventory service will still remove the item from their inventory, but if the auction service were to be down it will store the auction creation message in the queue for when it comes back up. When it does it will automatically take the message and post the auction.

Software Architecture Diagram (SAD)

This image can be a bit hard to read but it boils down to this:

The client can make REST calls to the backend services through the gateway. The gateway will route requests to the appropriate service. A user can register or login at the authentication service. The client will receive a token that will act as their identity. With that token the users client can make requests to the other services for things like retrieving the owned items.

The client can also set up a websocket connection to the ClientMessaging service and the Auction Service. The connection to the ClientMessaging service allows this service to push updates to the client without the client having to ask for them first. This is useful to notify the client when an item gets added to their inventory for example. The connection to the Auction service is used for subscribing to an auction. Subscribing to an auction allows the client to immediately receive bidding updates of an auction they might be interested in.

All other messaging between services is done with RabbitMQ for reasons explained above.