Event Driven vs REST in Microservice Architecture

What is a Microservice?

A microservice is a simple application that does one thing really well.

A microservice works in conjunction with other microservices to achieve what's known as service oriented architecture (SOA).

Microservices solve the problems introduced through monolithic applications. Monolithic applications are tightly coupled solutions that perform many tasks as a single, deployable solution.

A good example of a monolithic application would be a blog living on a single server. The database, service layer, and UI are deployed as one application. If the application crashes, the whole solution crashes. As the application grows, development complexity increases.

SOA or microservice based architecture solves these issues. Coming back to the blog example, let's say the solution exists as a collection of microservices. The UI could be deployed separately from the database and service layer.

A comments service could be deployed separately from a users service. If tons of users are singing up but not commenting on content then the user service can be scaled up without wasting resources on the comments service. Similarly, if there is an issue with the comments service it can be quickly fixed and deployed without bringing down the blogging platform as a whole.

Resiliency, scalability, and agility are the driving forces behind microservice architecture and it's ascent to the de-facto approach for architecting software solutions.

Still confused? Check out What is a microservice?

What is Event Driven Architecture?

Event driven architecture communicates changes in state over a pub/sub or producer/consumer model.

Event driven architecture leverages messaging frameworks like Kafka or MQ to establish a "push" based approach to communicating between services. While some microservices act as publishers of events, others act as consumers of those events to ultimately deliver a solution.

This approach is asynchronous in the sense that producer applications tend to "fire and forget" the messages they produce. Once a message is published, the producer application moves onto the next message without waiting for a response from the previous activity.

Of course there are exceptions to this (like in the case of manual acknowledgment with Kafka), however asynchronous communication is a key element of event driven architecture.

Still confused? Check out What is event driven architecture?

What is REST?

Representational state transfer (REST) is an architectural approach to communicating between clients and servers.

Using a uniform interface, REST APIs allow decoupled clients to communicate with servers with a request/response model.

GET, POST, PUT, DELETE are all HTTP methods commonly used to establish this uniform interface between clients and servers. You ca think of REST as an architectural "way of doing things" in terms of defining standardized APIs that clients can call.

For an API to be "RESTful" it typically abides by the following rules:

• Uniform interface: This is a fancy way of describing the decoupled relationship between clients and servers. While clients communicate with servers via a request/response model, they can be independently developed without requiring changes to the server as well.
• Stateless: RESTful APIs are stateless meaning when a client calls a server it receives all the information in a response payload. This response doesn't require any additional context and the calling client has all the info it needs from the response payload.
• Cacheable: A common functionality of a RESTful API is that the endpoints are cacheable by web browsers.
• Layered systems: RESTful APIs can communicate over several network hops including proxies and load balancers. This does not effect the request/response relationship.

To better understand what makes an API REStful you can dive deeper into REST vs SOAP and GraphQL vs REST.

Event Driven vs REST API Microservices

When evaluating event driven vs REST APIs, it's important to remember that microservices work together to deliver solutions. While event driven solutions can prove advantageous to the more traditional request/response model, RESTful APIs still have their place in today's world.

Consider authentication. In this scenario, a synchronous response is preferred. You can't "fire and forget' an event when a user logs in and hope that sometime later you authenticate the user. That's just not how authentication works.

This is why a combination of event driven and RESTful APIs usually work together to deliver an architected solution.

With that said, event driven approaches to solving problems have become exponentially popular as the nature and scale of applications changes.

Think about something like Uber where millions of vehicles are constantly sending their location to a centralized platform. The sheer volume and frequency of state changes warrant something event based. What would happen if every single vehicle had to evaluate a RESTful JSON response each time it updated its GPS coordinates? Imagine all of the unnecessary retry operations and the performance hit the network would take.

Or consider tracking user activity on a website. Capturing user actions through producing async events is much more efficient than waiting for HTTP requests to complete. This is how solutions like Google Analytics and other event logs achieve high performance and resilience in today's world.

For more ideas on event driven vs REST APIs, check out our forum on the difference between event driven and REST APIs.

Conclusion

The microservice based approach to designing scalable, resilient applications has become the de facto approach to software design.

While RESTful APIs present a request/response model to communicating between services, event driven solutions offer a more scalable producer / consumer relationship between different applications.

While microservices can communicate with each other through both events and REST APIs, the nature of event based communication and scalability of messaging platforms like Kafka have made event based architecture a dominant force in the world of software development today.

Developers may be quick to say "events are better" however there are still use cases where synchronous communication is preferred (like authentication). This is why a combination of both event driven and REST approaches are taken in modern day software design.

Your thoughts?