REST vs Event-Driven Architecture

REST Architecture

Ram is waiting for his breakfast at home. Every minute he is entering the kitchen to see if the food is ready. If he sees the food, he takes it and comes to the table. That’s how REST works → Pull Mechanism!!

REST API is mostly used for synchronous communication. In REST-based architecture, a microservice communicates with another one via REST calls. It is mostly used for authentication/authorization services. Though REST is quite simple to implement, highly scalable, and flexible, it’s not wise to rely on it if performance is of high priority.

Event-Driven Architecture [EDA]

Ram ordered food in Mcdonald’s. He is offered a token. He is waiting patiently looking at the screen because he knows very well that, the screen will immediately display the notification (that token number x is ready). Once he sees the notification, he just collects the food. That’s how EDA works → Push Mechanism.

Event-Driven Architecture (EDA) is used for asynchronous communication. In EDA, Microservice communicates with one another via message passing technologies like Kafka rather than REST API. Primarily used for logging, metrics type of services. Webhooks, Websockets, and Server-Sent Events are very common choices when we are dealing with Event-Driven Architecture.

If you rely on on-demand real-time data to take real-time decisions, Then Event-Driven Architecture is something you should always consider. It decouples the services very effectively, thus lack of tight coupling offers flexibility for services to work independently. Though it is super impressive, it comes with quite some trade-offs. Unlike REST, event-driven architecture is not that easy to decode the process steps as each service works independently. Sometimes, debugging will be a clumsy act here.

Of course, It’s not One Size fits all. Now getting much interest towards Pull vs Push Mechanism? Then just check my other article here.