Restful API and Event Driven microservices

Question

In an event-driven microservices system, is it usual or a best practice that the microservices are also restful APIs ?

In an event driven microservices, it is often described as some events being raised and some other microservices to respond to those events and do some actions. In this case, it seems like there is no concept of "resource" as in restful API. If a system is built using restful APIs, can this system be called as a microservice system ?

In the context of event-driven microservices, is the concept of restful still apply? I found myself a bit mixed up on these two as I start to learn more about event-driven micro and not sure if I have grasped the concept correct.

Answer 1

In an event-driven architecture, microservices don't communicate through REST APIs, but via a message passing framework (RabbitMQ, Kafka, etc.). As you correctly pointed out, microservices react to a message received on a particular topic/channel they listen to.

If the microservice is down, the message accumulates in the message bus and it gets processed either by the same microservice (when it gets back up) or by another one.

If they were to communicate through REST APIs and a microservice is down, you need to retry the request with an exponential backoff policy and take care of many other things. This article explains the difference really well.

A microservice system can be entirely built with REST microservices. It just doesn't follow the event-driven approach, but more like a synchronous (request/response) model. The design of your microservice system should be directly correlated to the requirements of your application.

Usually, a hybrid approach is used: you communicate with some microservices through REST APIs (for example with autentication/autorization microservices), because you need the response from them ASAP. With other ones, you can communicate through events, usually when you have fire-and-forget events, like logging, metrics, maybe storage.