concept message broker in category microservice

This is an excerpt from Manning's book Microservices Security in Action. Login to get full access to this book.

Another solution is for the authorization server to inform the API gateway whenever a token has been revoked. The gateway and authorization server can maintain this communication channel via a pub/sub (https://cloud.google.com/pubsub/docs/ overview) mechanism. This way, whenever a token is revoked, the gateway receives a message from the authorization server through a message broker. Then the gateway can maintain a list of revoked tokens until their expiry and before validating a given token check if it exists in the “revoked tokens” list. Revocations are rare, however. Figure 3.12 illustrates the revocation flow.

Figure 3.12 Executing the token revocation flow via a pub/sub mechanism. Upon a token revocation, the authorization server notifies the message broker, hence the API gateway.

In most cases, synchronous communications happen over HTTP. Asynchronous communications can happen over any kind of messaging system such as RabbitMQ, Apache Kafka, NATS, ActiveMQ, or even Amazon SQS. In this chapter, we discuss how to use Kafka and NATS as a message broker, which enables microservices to communicate with each other in an event-driven fashion, and how to secure the communication channels.

Figure 9.2 Introducing a message broker into the architecture. The Order Processing microservice calls the Payment microservice directly because payment is a mandatory and synchronous step in processing the order. It then emits an event to the message broker that delivers the order details to the rest of the microservices asynchronously. This makes the link between the Order Processing microservice and the other microservices indirect.

But with the reactive architecture, all we need to do is to make the Buying History microservice aware of the order event by linking it to a message broker. This way, the Buying History microservice gets to know the details of each order when an order is processed. This gives us the flexibility to add new functionality to the system without having to change and redeploy old code. Figure 9.3 illustrates the introduction of the Buying History microservice into this architecture.