Microservices Patterns by Chris Richardson Chapter 6 Developing business logic with event sourcing

Event sourcing is a different way of structuring the business logic and persisting aggregates. It persists an aggregate as a sequence of events. Each event represents a state change of the aggregate. An application recreates the current state of an aggregate by replaying the events.

Traditional applications usually use RDB and ORM approach for data persistence. But it has several drawbacks and limitations:

  • Object-Relational impedance mismatch.

  • Lack of aggregate history.

  • Implementing audit logging is tedious and error prone.

  • Event publishing is bolted on to the business logic.

If an application potentially may produce too many state changes of aggregate – than it worth to implement snapshots and replay events only from the last snapshot for getting current state.

Managing event schema evolution might be challenging due to not all changes of events are backward compatible (renaming, changing type of field, etc.). Upcaster mechanism resolves this challenge. It works similar to schema migrations for SQL databases. It does not change existing events instead updates individual events from an old version to a newer version. As a result, the application code only ever deals with the current event schema.

Deleting data might be tricky. It's possible to implement soft delete with deletion flag in database. But due to General Data Protection Regulation, a European data protection and privacy regulation that grants individuals the right to erasure. An application must have the ability to forget a user’s personal information, such as their email address. Encryption is one mechanism you can use to solve this problem. Each user has an encryption key, which is stored in a separate database table. The application uses that encryption key to encrypt any events containing the user’s personal information before storing them in an event store. When a user requests to be erased, the application deletes the encryption key record from the database table. The user’s personal information is effectively deleted, because the events can no longer be decrypted.

Querying the event store also might be challenging. Consequently, you must implement queries using the CQRS approach described in chapter 7.

Connect with me on LinkedIn