Why Microservices Should use Event Sourcing
6 Reasons where you need to use Event Sourcing in Micro-services
Microservices play a vital role when migrating from monolithic applications. They help improve applications’ scalability, manageability, agility, or speed of delivery.
However, there are some challenges in using microservices, such as state handling. As developers, it is indispensable for us to know how to overcome these issues to get the maximum out of microservices.
Using event sourcing is a great solution for most of these issues. So, in this article, I will discuss why we should use event sourcing with microservices and the advantages of using it.
What is Event Sourcing
Event Sourcing is an alternative way to persist data. Compared to other state persistence methods like state-oriented persistence, event sourcing stores all the state mutations as a separate record called an event.
For example, when a customer puts items to a cart in an online buying platform, event sourcing saves all the state changes in the cart as a list of state-changing events. Whenever the state of an entity changes, a new event is appended to the list of events.
1. Smooth Transition from Domain-Driven Design
When it comes to the designing stage of a project, developers and designers analyze the domain and do event storming/event modeling. The objective here is to identify the project from a pure design standpoint.
However, a part of the conversation is highly event-oriented. So the outcome of the effort is microservices that developers will build. Therefore, the commands and events go into these different microservices.
Event sourcing comes in the stage of implementation. First, the code and the system’s data flow are implemented using event sourcing as the design has been done with the event mindset.
2. Reducing Coupling
Assume a scenario where two microservices loosely couple. If a design, implementation, or behavior change happens in one microservice, it won’t cause another change.
However, when it comes to microservices, the coupling can happen. For example, if a change is made to a microservice, it will cause all other microservices to collaborate with the first one directly or indirectly.
3. Optimizes the Read vs. Write performance Bottleneck
Imagine a typical system with many operations that are probably built over the years and managed by a single database. However, the database can be optimized for reads and writes when performing CRUD operations.
But it’s always a trade-off. If you optimize for reads, it comes with the expense of writes. If you optimize for writes, it comes with expensive reads. So there are obvious, significant trade-offs that are going on.
However, event sourcing solves the problem. When it comes to event sourcing, it uses segregated persistence. That is to say, we have got the event store that is inserting events. All the CRUD operations become just storage and events. All those events aggregate to this current operation state that developers need to execute.
The real advantage of the event store here is the expense of the user, and the bottleneck of read-write operations will decrease.
4. Elevate the concurrency barrier
There is a greater probability of getting a traffic spike in large enterprise applications. Such scenarios can affect the application database and solving them can be painful.
Yes, these issues can be solved by spending three or four weeks. But, you can still run into a situation where the database is just pushed to its limit.
This is another reason why event sourcing is increasingly becoming a popular approach. Event sourcing handles this issue by writing and inserting records in the spike into the event log and not letting the read-side wait.
5. Simplify and harden messaging
The semantics of messaging in microservices can be broken down into three categories.
- In most once — Cases where a message might not get delivered, and you will lose messages under certain circumstances. When thinking about the microservice we build, this is not an acceptable feature.
- At least once — The category is the easiest to be implemented. In this case, a message can be delivered at least once. On the other hand, a certain message can be delivered more than twice.
- Exactly once — A reasonably mythical method and hard to implement but still doable from the consumer perspective.
There are some scenarios where messages do not deliver the first time. So the solution will be implementing a retry logic.
When developers implement a retry logic, they have to start thinking about cases like producer services trying to publish data. It has to be capable of being in that mode where some messages haven’t been delivered.
Also, cases like the service go down. And when that service comes back, can it pick up where it left off and continue to retry sending those messages? Such situations bring much complexity to the producer.
Also, imagine a scenario where a service does a database transaction first, and then it makes a call to Kafka. Since these are two separate transactions, first the database transaction will occur. However, the message in Kafka will not pass. So that’s a leak in the pipe, and the consumers have a potential vulnerability. When the service goes down during that exposure period, the messages will be lost.
When using event sourcing, developers do not need to worry about failing messages. So here, the messages aren’t pushed to Kafka consumers. Kafka consumers pull, and it is easier to implement this pull pattern.
6. Eliminate service coupling
Imagine a situation where we have customer service helping a few other services. If the customer service goes down, additional services will also go down.
When using event sourcing, the approach is that the customer publishes and the other services consume. In such a case, if the customer service goes out, there is no harm until it gets back.
Conclusion
Microservices architecture is one of the commonly used architectures in backend development. However, it is crucial to know how to use it in a much optimized and hassle-free manner.
In this article, I have explained 06 reasons why you should use event soucing with microservice to avoid common pitfalls.
I hope this article will help you develop microservices in a much more optimized way. Thank you for reading.
Bit: Feel the power of component-driven dev
Say hey to Bit. It’s the #1 tool for component-driven app development.
With Bit, you can create any part of your app as a “component” that’s composable and reusable. You and your team can share a toolbox of components to build more apps faster and consistently together.
- Create and compose “app building blocks”: UI elements, full features, pages, applications, serverless, or micro-services. With any JS stack.
- Easily share, and reuse components as a team.
- Quickly update components across projects.
- Make hard things simple: Monorepos, design systems & micro-frontends.
