Event store concept in Microservices - System Design Guide

Problem Statement

When a system only stores the current state of data, it loses the history of how that state was reached. This makes debugging, auditing, and recovering past states difficult or impossible, especially in complex microservices where state changes happen frequently and asynchronously.

Solution

An event store records every change to the system as a sequence of events, preserving the full history. Instead of just saving the latest state, it saves all state transitions, allowing the system to reconstruct past states by replaying events. This approach supports audit trails, debugging, and temporal queries.

Architecture

Command/API

(Client)

→Event Store

↓

Read Models /

Read Models /

This diagram shows how commands from clients generate events stored in an append-only event store. Events are then published to processors that update read models or trigger side effects.

Trade-offs

✓ Pros

→

Preserves full history of all changes, enabling audit and debugging.

→

Supports rebuilding system state at any point in time by replaying events.

→

Decouples write and read models, improving scalability and flexibility.

→

Facilitates event-driven architectures and asynchronous processing.

✗ Cons

→

Increases storage requirements since all events are kept indefinitely.

→

Requires careful design for event versioning and schema evolution.

→

Adds complexity in rebuilding current state and handling eventual consistency.

Use when system requires audit trails, temporal queries, or complex state transitions in microservices with asynchronous workflows and high scalability needs.

Avoid when system is simple CRUD with low change volume or when event replay and history are not needed, as complexity and storage overhead outweigh benefits.

Real World Examples

Uber

Uber uses event sourcing to track ride state changes and payments, enabling reliable audit and recovery of ride histories.

LinkedIn

LinkedIn employs event stores to capture user activity streams, allowing reconstruction of user timelines and analytics.

Amazon

Amazon uses event sourcing in parts of its order processing system to maintain a complete history of order state changes for auditing and troubleshooting.

Code Example

The before code updates the account balance directly, losing history. The after code appends each change as an event to the event store and applies it, preserving full change history and enabling state reconstruction.

Microservices

### Before: naive state update without event store
class Account:
    def __init__(self):
        self.balance = 0

    def deposit(self, amount):
        self.balance += amount

    def withdraw(self, amount):
        self.balance -= amount


### After: event store records all changes as events
class EventStore:
    def __init__(self):
        self.events = []

    def append(self, event):
        self.events.append(event)

    def get_events(self):
        return self.events

class Account:
    def __init__(self, event_store):
        self.balance = 0
        self.event_store = event_store
        self.replay_events()

    def replay_events(self):
        for event in self.event_store.get_events():
            self.apply(event)

    def apply(self, event):
        if event['type'] == 'deposit':
            self.balance += event['amount']
        elif event['type'] == 'withdraw':
            self.balance -= event['amount']

    def deposit(self, amount):
        event = {'type': 'deposit', 'amount': amount}
        self.event_store.append(event)
        self.apply(event)

    def withdraw(self, amount):
        event = {'type': 'withdraw', 'amount': amount}
        self.event_store.append(event)
        self.apply(event)

Alternatives

State-based persistence

Stores only the current state snapshot instead of all changes as events.

Use when: Choose when system complexity is low and full history or temporal queries are not required.

Command Query Responsibility Segregation (CQRS)

Separates read and write models but does not necessarily store all events; can be combined with event store.

Use when: Choose when you want to optimize read and write workloads separately, possibly alongside event sourcing.

Summary

Event store records every change as an immutable event, preserving full history.

It enables rebuilding system state by replaying events and supports audit and debugging.

Event sourcing adds complexity and storage needs but is valuable for complex, scalable microservices.