Event sourcing pattern in Microservices - System Design Guide

Problem Statement

When systems store only the current state, any data corruption or bugs can cause permanent loss of historical information. This makes debugging, auditing, and recovering past states difficult or impossible. Additionally, concurrent updates can lead to conflicts without a clear history of changes.

Solution

Event sourcing solves this by storing every change to the system as a sequence of events. Instead of saving just the latest state, the system records all state changes in order. The current state can be rebuilt anytime by replaying these events, providing a complete history and enabling easier debugging and recovery.

Architecture

Client/Service

→Event Store

↓

Event Replay

This diagram shows how client requests generate events stored in the event store. Events are processed and can be replayed to rebuild the current state or update read models.

Trade-offs

✓ Pros

→

Provides a complete audit trail of all changes for debugging and compliance.

→

Enables easy recovery of past states by replaying events.

→

Supports complex business logic with clear event history.

→

Facilitates integration with other systems via event streams.

✗ Cons

→

Increases storage needs since all events are kept indefinitely.

→

Rebuilding state by replaying events can be slow if event history is large.

→

Requires careful design to handle event versioning and schema evolution.

Use when auditability, traceability, or complex state transitions are critical, especially in systems with high write volumes or complex business rules.

Avoid when system state changes are simple and infrequent, or when storage and replay overhead outweigh benefits, such as small-scale CRUD apps.

Real World Examples

Amazon

Uses event sourcing in order management to track every change in order status, enabling full audit and recovery.

Uber

Applies event sourcing to track trip lifecycle events, allowing reconstruction of trip states and debugging of issues.

LinkedIn

Uses event sourcing for activity feeds to capture user actions as events, enabling flexible feed generation and replay.

Code Example

The before code updates the account balance directly, losing history. The after code records each change as an event in an event store and rebuilds the balance by replaying these events, preserving full history.

Microservices

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

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

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


### After: event sourcing with event log
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

CRUD-based state storage

Stores only the current state in a database without recording changes as events.

Use when: When system complexity is low and audit/history is not required.

Command Query Responsibility Segregation (CQRS)

Separates read and write models but does not necessarily store all changes as events.

Use when: When read and write workloads differ significantly but full event history is not needed.

Summary

Event sourcing stores all changes as a sequence of events instead of just current state.

This pattern enables full history tracking, easier debugging, and state recovery by replaying events.

It is best suited for systems requiring audit trails or complex state transitions but adds storage and complexity overhead.

Practice

1. What is the main idea behind the Event sourcing pattern in microservices?

easy

A. Store all changes as a sequence of events instead of only the current state

B. Store only the latest snapshot of data for faster access

C. Use events only for communication between services, not for storage

D. Store events only when errors occur in the system

Solution

1. Step 1: Understand event sourcing concept

   Event sourcing means saving every change as an event, not just the final state.

2. Step 2: Compare options with definition

   Only Store all changes as a sequence of events instead of only the current state correctly describes storing all changes as events, others focus on snapshots or partial use.

3. Final Answer:

   Store all changes as a sequence of events instead of only the current state -> Option A

4. Quick Check:

   Event sourcing = storing all changes as events [OK]

Hint: Event sourcing saves every change, not just the final state [OK]

Common Mistakes:

• Confusing event sourcing with snapshot storage
• Thinking events are only for communication
• Believing events are stored only on errors

2. Which of the following is the correct sequence in event sourcing when a user updates their profile?

easy

A. Update state directly, then create an event for the change

B. Send event to other services before updating state

C. Create an event representing the change, then update the state from the event

D. Store the new state without creating any event

Solution

1. Step 1: Recall event sourcing flow

   In event sourcing, changes are first recorded as events, then state is updated from those events.

2. Step 2: Match options to flow

   Create an event representing the change, then update the state from the event correctly shows event creation before state update; others do not follow this order.

3. Final Answer:

   Create an event representing the change, then update the state from the event -> Option C

4. Quick Check:

   Event first, then state update = Create an event representing the change, then update the state from the event [OK]

Hint: Events come before state updates in event sourcing [OK]

Common Mistakes:

• Updating state before creating events
• Skipping event creation
• Sending events before state is updated

3. Given this simplified event sourcing code snippet, what will be the final user balance?

events = [
  {"type": "Deposit", "amount": 100},
  {"type": "Withdraw", "amount": 30},
  {"type": "Deposit", "amount": 50}
]

balance = 0
for event in events:
    if event["type"] == "Deposit":
        balance += event["amount"]
    elif event["type"] == "Withdraw":
        balance -= event["amount"]
print(balance)

medium

A. 80

B. 150

C. 100

D. 120

Solution

1. Step 1: Calculate deposits and withdrawals

   Deposits: 100 + 50 = 150; Withdrawals: 30

2. Step 2: Compute final balance

   Balance = 0 + 150 - 30 = 120

3. Final Answer:

   120 -> Option D

4. Quick Check:

   Deposits minus withdrawals = 120 [OK]

Hint: Add deposits, subtract withdrawals to find balance [OK]

Common Mistakes:

• Adding withdrawals instead of subtracting
• Ignoring last deposit event
• Starting balance not zero

4. In an event sourcing system, which issue is caused by missing an event during state reconstruction?

medium

A. System crashes immediately

B. State becomes inconsistent or incorrect

C. Events are duplicated in the event store

D. Commands fail to generate new events

Solution

1. Step 1: Understand event replay in event sourcing

   State is rebuilt by replaying all events in order.

2. Step 2: Effect of missing an event

   If an event is missing, the rebuilt state will not reflect all changes, causing inconsistency.

3. Final Answer:

   State becomes inconsistent or incorrect -> Option B

4. Quick Check:

   Missing event = incorrect state [OK]

Hint: Missing events cause wrong state, not crashes [OK]

Common Mistakes:

• Assuming system crashes on missing event
• Confusing missing event with duplicate events
• Thinking commands stop working due to missing event

5. You are designing a microservice using event sourcing. To improve performance, you want to avoid replaying all events every time. Which approach is best to achieve this?

hard

A. Use snapshots to save periodic state and replay only recent events

B. Store only the latest event and discard older ones

C. Send all events to other services for processing

D. Update state directly and ignore events after initial load

Solution

1. Step 1: Identify performance issue in event sourcing

   Replaying all events from the start can be slow as event count grows.

2. Step 2: Choose solution to reduce replay time

   Snapshots save the current state at intervals, so only recent events need replaying.

3. Final Answer:

   Use snapshots to save periodic state and replay only recent events -> Option A

4. Quick Check:

   Snapshots improve replay speed [OK]

Hint: Snapshots speed up state rebuild by reducing event replay [OK]

Common Mistakes:

• Discarding old events breaks event sourcing
• Sending all events elsewhere doesn't reduce replay
• Ignoring events after initial load loses audit trail