System Design

Event-Driven Architecture

Build loosely coupled systems using events. Explore pub/sub, event sourcing, and CQRS.

Core Patterns

📡

Publish/Subscribe

Producers publish events without knowing who consumes them. Subscribers listen for events they care about, enabling loose coupling between services.

DecouplingFan-outTopics

Use case:Order events distributed to inventory, notifications, and analytics services simultaneously

📜

Event Sourcing

Store every state change as an immutable event. Reconstruct current state by replaying the event log. Full audit trail and time-travel debugging.

ImmutableAudit TrailReplay

Use case:Banking ledger, e-commerce order history, version control systems

✂️

CQRS

Command Query Responsibility Segregation separates read and write models for independent scaling, optimization, and security. Often paired with Event Sourcing.

Read/Write SplitScalingProjections

Use case:High-traffic dashboards reading from optimized views while writes go through domain validation

🎭

Saga Pattern

Manage distributed transactions across microservices using a sequence of local transactions with compensating actions for rollback on failure.

Distributed TxCompensationOrchestration

Use case:E-commerce checkout: payment → inventory → shipping, with automatic rollback if any step fails

Architecture Overview

How events flow through an event-driven system

sequenceDiagram
    participant P as Publisher
    participant EB as Event Bus
    participant S1 as Subscriber A
    participant S2 as Subscriber B
    participant ES as Event Store

    P->>EB: Emit OrderCreated Event
    EB->>ES: Persist Event (Append-Only)
    EB-->>S1: Deliver Event
    EB-->>S2: Deliver Event
    S1->>S1: Process (Update Inventory)
    S2->>S2: Process (Send Notification)
    S1-->>EB: ACK
    S2-->>EB: ACK
    Note over ES: Full audit trail preserved
    Note over EB: Events are immutable & replayable

Interactive Flow Patterns

Explore event-driven patterns with step-by-step animations

Waiting...

Publish/Subscribe: Decouple Producers from Consumers

📤PUBLISHER

Order Service

⚡EVENTBUS

Kafka / SNS

📦SUB1

Inventory

🔔SUB2

Notifications

1. Publisher emits "OrderCreated" event

2. Event Bus receives and stores the event

3. Event Bus routes event to all subscribers

4. Inventory service processes order event

5. Notification service sends confirmation

6. Both subscribers ACK independently

✓ Loose coupling — Publisher never knows about subscribers

Publisher / Command

Event Bus / Store

Subscriber / Handler

Persistence

Key Concepts

Essential principles for building robust event-driven systems

Idempotency

Events may be delivered more than once. Consumers must handle duplicates gracefully — processing the same event twice should produce the same result.

Tip: Use unique event IDs + a processed events table to deduplicate

Event Ordering

In distributed systems, events may arrive out of order. Use sequence numbers, timestamps, or partition keys to maintain ordering guarantees where needed.

Tip: Kafka guarantees order within a partition; use consistent partition keys

Schema Evolution

As your system evolves, event schemas change. Use versioning (v1, v2) and backward-compatible changes to avoid breaking existing consumers.

Tip: Use Avro/Protobuf with a schema registry for safe evolution

Pattern Comparison

Compare event-driven patterns by key characteristics

Pattern	Complexity	Scalability	Consistency	Debuggability	Best For
Pub/Sub					Loose coupling, fan-out, event broadcasting
Event Sourcing					Audit trails, replay, temporal queries
CQRS					Read-heavy workloads, independent scaling
Saga					Distributed transactions, compensating actions

Resources

Title	Type	Link
Event-Driven Architecture — Martin Fowler	web	Open
Master Event Sourcing in Just 10 Minutes	youtube	Open
Mastering CQRS in Just 5 Minutes	youtube	Open
CQRS Pattern — Microsoft Docs	web	Open
Saga Pattern — Microservices.io	web	Open

Guide Contributors

ObydulSenior Software Engineer

Edit this page on GitHub↗

Init guide environment...

Core Patterns

📡

Publish/Subscribe

Producers publish events without knowing who consumes them. Subscribers listen for events they care about, enabling loose coupling between services.

DecouplingFan-outTopics

Use case:Order events distributed to inventory, notifications, and analytics services simultaneously

📜

Event Sourcing

Store every state change as an immutable event. Reconstruct current state by replaying the event log. Full audit trail and time-travel debugging.

ImmutableAudit TrailReplay

Use case:Banking ledger, e-commerce order history, version control systems

✂️

CQRS

Command Query Responsibility Segregation separates read and write models for independent scaling, optimization, and security. Often paired with Event Sourcing.

Read/Write SplitScalingProjections

Use case:High-traffic dashboards reading from optimized views while writes go through domain validation

🎭

Saga Pattern

Manage distributed transactions across microservices using a sequence of local transactions with compensating actions for rollback on failure.

Distributed TxCompensationOrchestration

Use case:E-commerce checkout: payment → inventory → shipping, with automatic rollback if any step fails

Architecture Overview

How events flow through an event-driven system

sequenceDiagram
    participant P as Publisher
    participant EB as Event Bus
    participant S1 as Subscriber A
    participant S2 as Subscriber B
    participant ES as Event Store

    P->>EB: Emit OrderCreated Event
    EB->>ES: Persist Event (Append-Only)
    EB-->>S1: Deliver Event
    EB-->>S2: Deliver Event
    S1->>S1: Process (Update Inventory)
    S2->>S2: Process (Send Notification)
    S1-->>EB: ACK
    S2-->>EB: ACK
    Note over ES: Full audit trail preserved
    Note over EB: Events are immutable & replayable

Interactive Flow Patterns

Explore event-driven patterns with step-by-step animations

Waiting...

Publish/Subscribe: Decouple Producers from Consumers

📤PUBLISHER

Order Service

⚡EVENTBUS

Kafka / SNS

📦SUB1

Inventory

🔔SUB2

Notifications

1. Publisher emits "OrderCreated" event

2. Event Bus receives and stores the event

3. Event Bus routes event to all subscribers

4. Inventory service processes order event

5. Notification service sends confirmation

6. Both subscribers ACK independently

✓ Loose coupling — Publisher never knows about subscribers

Publisher / Command

Event Bus / Store

Subscriber / Handler

Persistence

Key Concepts

Essential principles for building robust event-driven systems

Idempotency

Events may be delivered more than once. Consumers must handle duplicates gracefully — processing the same event twice should produce the same result.

Tip: Use unique event IDs + a processed events table to deduplicate

Event Ordering

In distributed systems, events may arrive out of order. Use sequence numbers, timestamps, or partition keys to maintain ordering guarantees where needed.

Tip: Kafka guarantees order within a partition; use consistent partition keys

Schema Evolution

As your system evolves, event schemas change. Use versioning (v1, v2) and backward-compatible changes to avoid breaking existing consumers.

Tip: Use Avro/Protobuf with a schema registry for safe evolution

Pattern Comparison

Compare event-driven patterns by key characteristics

Pattern	Complexity	Scalability	Consistency	Debuggability	Best For
Pub/Sub					Loose coupling, fan-out, event broadcasting
Event Sourcing					Audit trails, replay, temporal queries
CQRS					Read-heavy workloads, independent scaling
Saga					Distributed transactions, compensating actions

Resources

Title	Type	Link
Event-Driven Architecture — Martin Fowler	web	Open
Master Event Sourcing in Just 10 Minutes	youtube	Open
Mastering CQRS in Just 5 Minutes	youtube	Open
CQRS Pattern — Microsoft Docs	web	Open
Saga Pattern — Microservices.io	web	Open

Guide Contributors

ObydulSenior Software Engineer