To handle events flowing through the microservice application, microservices may use the event sourcing pattern. Event sourcing persists the state of a business entity as a sequence of state-changing events. For example, a bank account may be represented as an initial amount of money and a sequence of deposit/withdraw operations. Having this information not only allows us to calculate the current account state by replaying update events, it also gives a reliable audit log of the entity changes and allows queries to determine the state of an entity at any point in the past. Usually, services that implement event sourcing provide APIs that allow other services to subscribe to entities updates.
To optimize the time required to calculate the current state, an application can periodically build and save snapshots. To reduce the storage size, events before the selected snapshot may be deleted. In this case, it is clear that a part of the entire history of updated events is lost.
Bank Account 111-11 event log:
| Date | Action | Amount |
| 2018-06-04 22:00:01 | create | $0 |
| 2018-06-05 00:05:00 | deposit | $50 |
| 2018-06-05 09:30:00 | withdraw | $10 |
| 2018-06-05 14:00:30 | deposit | $20 |
| 2018-06-06 15:00:30 | deposit | $115 |
| 2018-06-07 10:10:00 | withdraw | $40 |
Current balance: $135
Despite its simplicity, event sourcing is not used frequently due to its unfamiliar and slightly alien programming approach, as well as its learning curve. Also, because of the constant state recalculation, event sourcing does not allow efficient querying, especially when queries are complicated. In this case, Command Query Responsibility Segregation may help.