If you’re an enterprise architect, you’ve probably heard of and worked with a microservices architecture. And while you might have used REST as your service communications layer in the past, more and more projects are moving to an event-driven architecture. Let’s dive into the pros and cons of this popular architecture, some of the key design choices it entails, and common anti-patterns.
Very comprehensive article.
Regarding streams-based event-driven microservices using Kafka, I would just add that it enables local materialized views which allows you to keep the application state close to the services with no hassles, you may check my post.
I would add orchestration as another approach to event-driven service architecture. In the large set of use cases it is much better fit than choreography described in this article. Look at the example of the beginning of the article:
- the order service which could write an order record to the database
- the customer service which could create the customer record, and
- the payment service which could process the payment.
A real application would never create payment, customer and order records based on a single message as the above three services have to coordinate between them to achieve the business objective. For example the payment should be processed only after the order is shipped and not processed if there is not enough inventory. Orchestration solves this problem much cleaner as it allows to specify the whole business transaction is a centralized component.
I would recommend to look at the Cadence Workflow which is an open source developer friendly orchestrator developed by Uber. For example it is used to process tip requests in Uber application.
Disclamer: I’m tech lead of the Cadence project.
Great article, Jason. I enjoyed reading it.
I’d add that now it’s possible to have your event-driven architecture documented with AsyncAPI. Disclaimer: I’m the AsyncAPI creator.