What is Event-Driven Design - Introduction To Event Driven Design | OneNoughtOne

0/246

System Design (LLD)Event-Driven Design

Introduction to Event-Driven Design

LevelIntermediate

Duration60 mins

TopicEvent-Driven Design

1 / 4

What is Event-Driven Design

Rethinking How Systems Communicate

In traditional software design, components communicate through direct method calls. Service A needs something from Service B, so it calls serviceB.doSomething(). This is intuitive, explicit, and mirrors how we naturally think about programming. But as systems grow in complexity, this direct coupling becomes a liability.

What if Service B changes its interface? Service A must change too. What if Service A needs to notify five different services? It must know about all of them. What if Service B is temporarily unavailable? Service A must handle the failure.

Event-driven design offers a fundamentally different approach: instead of telling other components what to do, a component simply announces what happened. It publishes an event—a record of a fact that occurred—and allows interested parties to react as they see fit. The component doesn't need to know who's listening, what they'll do, or even if anyone is listening at all.

What You Will Learn

By the end of this page, you will understand the fundamental concepts of event-driven design: what events are, the difference between synchronous and asynchronous communication, and the core mental model shift from 'commanding' to 'announcing.' You will be equipped to recognize when event-driven patterns apply and understand why they enable more flexible, scalable, and maintainable systems.

What Exactly Is an Event?

At its core, an event is a record of something that happened in the past. This definition is deceptively simple, but its implications are profound.

Key Characteristics of Events:

Events are immutable facts. Once an OrderPlaced event occurred, it cannot be undone—it happened. You might later have an OrderCancelled event, but the original event remains a permanent record.
Events are named in past tense. UserRegistered, PaymentProcessed, InventoryUpdated—always describing something that has already occurred, never something that should occur.
Events carry relevant data. An event contains the information that interested parties need to understand what happened: the order ID, the user details, the amount paid, the timestamp.
Events have no expectation of response. When a component publishes an event, it does so without expecting any particular outcome. It's fire-and-forget from the publisher's perspective.

events.ts
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
// Events are immutable records of facts that occurred
// Notice the past-tense naming: something HAS happened
 
interface DomainEvent {
    readonly eventId: string;           // Unique identifier for this specific event
    readonly eventType: string;         // The type of event (e.g., "OrderPlaced")
    readonly occurredAt: Date;          // When the event occurred
    readonly aggregateId: string;       // The entity this event relates to
    readonly payload: Readonly<object>; // The event-specific data
}
 
// Example: A concrete event representing an order being placed
interface OrderPlacedEvent extends DomainEvent {
    eventType: "OrderPlaced";
    payload: Readonly<{
        orderId: string;
        customerId: string;
        items: ReadonlyArray<{
            productId: string;
            quantity: number;
            unitPrice: number;
        }>;
        totalAmount: number;
        shippingAddress: Readonly<{
            street: string;
            city: string;
            postalCode: string;
            country: string;
        }>;
    }>;
}
 
// Example: Another event in the order lifecycle
interface OrderShippedEvent extends DomainEvent {
    eventType: "OrderShipped";
    payload: Readonly<{
        orderId: string;
        trackingNumber: string;
        carrier: string;
        estimatedDelivery: Date;
    }>;
}
 
// Events are facts—this order WAS placed, this order WAS shipped
// Nothing about these events requests action; they simply record history

Immutability Is Not Optional

Events must be immutable. If an event could be modified after creation, you'd lose the guarantee that it accurately represents what happened at that moment. Use readonly in TypeScript, final in Java, or frozen objects in Python. Immutability ensures that events remain trustworthy historical records.

The Mental Model Shift: From Commanding to Announcing

Understanding event-driven design requires a fundamental shift in how you think about inter-component communication. Let's contrast the two approaches:

Traditional Approach (Command-Oriented):

Component A tells Component B what to do
Communication is imperative: "Do this!"
Component A has direct knowledge of Component B
Component A waits for (and depends on) Component B's response

Event-Driven Approach:

Component A announces what happened
Communication is declarative: "This happened."
Component A has no knowledge of who might be listening
Component A continues without waiting for any response

This shift has profound implications for how systems are structured and how they evolve over time.

Command-Oriented (Tight Coupling)

•OrderService calls InventoryService.reserve()
•OrderService calls PaymentService.charge()
•OrderService calls NotificationService.sendEmail()
•OrderService calls AnalyticsService.trackOrder()
•OrderService knows and depends on 4 services
•Adding a new recipient requires changing OrderService
•If any service is down, the order might fail

Event-Driven (Loose Coupling)

•OrderService publishes OrderPlaced event
•InventoryService subscribes & reserves stock
•PaymentService subscribes & processes payment
•NotificationService subscribes & sends email
•AnalyticsService subscribes & tracks order
•OrderService knows about zero other services
•Adding recipients doesn't change OrderService

The newspaper analogy:

Think of the command-oriented approach like making individual phone calls. You need the phone number of everyone you want to reach, you must call them one by one, and if someone doesn't answer, you have to decide what to do.

The event-driven approach is like publishing a newspaper. You announce the news once, and anyone interested can read it. You don't need to know who your subscribers are. If someone takes a vacation, the newspaper still publishes—they can catch up when they return. Adding a new subscriber doesn't require any change to your publishing process.

This analogy captures the essence of why event-driven systems are more flexible: the publisher is insulated from changes in the subscriber base.

Inversion of Dependencies

In command-oriented design, the publisher depends on its consumers. In event-driven design, this is inverted: consumers depend on the events they subscribe to, but publishers are blissfully unaware of consumers. This is a form of the Dependency Inversion Principle at the architectural level.

Synchronous vs Asynchronous Event Processing

A common point of confusion is the relationship between event-driven design and asynchronous processing. While event-driven systems are often asynchronous, they don't have to be. Understanding the distinction is crucial.

Synchronous Event Processing:

The publisher waits until all handlers have processed the event
Simpler to reason about; easier to debug
The publisher gets immediate feedback if processing fails
But: still provides decoupling—publisher doesn't know which handlers run

Asynchronous Event Processing:

The publisher continues immediately after publishing
Events are typically queued and processed later
Better for scalability and resilience
But: more complex error handling and eventual consistency

event-processing.ts
TypeScript
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
// ===== SYNCHRONOUS EVENT DISPATCHING =====
// Publisher waits for all handlers to complete
 
class SynchronousEventDispatcher {
    private handlers: Map<string, EventHandler[]> = new Map();
    
    subscribe(eventType: string, handler: EventHandler): void {
        const existing = this.handlers.get(eventType) || [];
        this.handlers.set(eventType, [...existing, handler]);
    }
    
    // Synchronous: awaits all handlers before returning
    async dispatch(event: DomainEvent): Promise<void> {
        const handlers = this.handlers.get(event.eventType) || [];
        
        // All handlers execute before this method returns
        // Publisher has the option to catch errors
        for (const handler of handlers) {
            await handler.handle(event);
        }
    }
}
 
// Usage: Publisher waits for completion
class OrderService {
    constructor(private eventDispatcher: SynchronousEventDispatcher) {}
    
    async placeOrder(order: Order): Promise<void> {
        // ... order creation logic ...
        
        // Publisher waits here until ALL handlers complete
        await this.eventDispatcher.dispatch(new OrderPlacedEvent(order));
        
        // Code here runs AFTER all handlers finished
        console.log("All handlers processed the order");
    }
}
 
// ===== ASYNCHRONOUS EVENT DISPATCHING =====
// Publisher continues immediately; events processed later
 
class AsynchronousEventDispatcher {
    constructor(private messageQueue: MessageQueue) {}
    
    // Asynchronous: returns immediately after queuing
    async dispatch(event: DomainEvent): Promise<void> {
        // Event is sent to a queue/broker
        // Actual processing happens later, possibly on different machines
        await this.messageQueue.publish("events", event);
        
        // This returns as soon as the event is queued
        // NOT when it's processed
    }
}
 
// Usage: Publisher doesn't wait for processing
class OrderServiceAsync {
    constructor(private eventDispatcher: AsynchronousEventDispatcher) {}
    
    async placeOrder(order: Order): Promise<void> {
        // ... order creation logic ...
        
        // Publisher continues immediately after queuing
        await this.eventDispatcher.dispatch(new OrderPlacedEvent(order));
        
        // Code here runs BEFORE handlers might have processed
        // The order is "eventually" handled, not immediately
        console.log("Order queued for processing");
    }
}

Synchronous vs Asynchronous Event Processing
Aspect	Synchronous	Asynchronous
Processing timing	Immediate, within same request/transaction	Deferred, possibly much later
Publisher behavior	Blocks until handlers complete	Continues immediately after dispatch
Error handling	Errors propagate to publisher	Errors handled separately (dead-letter queues, retries)
Consistency model	Strong consistency feasible	Eventual consistency typical
Scalability	Limited by slowest handler	Independent scaling of publishers/consumers
Debugging difficulty	Easier (synchronous flow)	Harder (distributed tracing needed)
Infrastructure	In-process dispatcher	Message broker/queue required

Start Simple, Scale When Needed

A common mistake is jumping straight to asynchronous processing with message brokers. Start with synchronous in-process event dispatching. It provides the decoupling benefits of event-driven design without the complexity of distributed systems. Migrate to asynchronous when you have proven performance or reliability requirements that demand it.

Event-Driven Design in Software Architecture

Event-driven design isn't an all-or-nothing proposition. It's a technique you apply selectively within your architecture. Understanding where it fits helps you make principled decisions about when to use it.

Where Event-Driven Design Commonly Appears:

Within a single application (Domain Events): Components within a monolith or microservice communicate via events to stay decoupled. This is "small-scale" event-driven design and is the focus of Low-Level Design.
Between services (Integration Events): Microservices publish events to notify other services of state changes. This involves message brokers, eventual consistency, and distributed systems concerns.
Between systems (Enterprise Integration): Different applications or even different organizations communicate via events using enterprise messaging patterns.
User Interface (UI Events): Front-end frameworks use events for user interactions—clicking, typing, scrolling. The browser's event model is inherently event-driven.
Hardware and Operating Systems: Interrupts, file system watchers, network sockets—low-level systems are fundamentally event-driven.

Event-Driven Design at the LLD Level:

This module focuses on event-driven patterns within a single codebase or service. We're concerned with:

How to model domain events in your object design
How to implement event publishers and handlers
How to test event-driven code
How to maintain code clarity despite the indirection events introduce

We're not (primarily) concerned with Kafka, RabbitMQ, or distributed systems—those are High-Level Design (HLD) topics. Our goal is to design classes and modules that communicate through events effectively, cleanly, and maintainably.

LLD Event-Driven Concerns

•Event Modeling: How do we design event classes that capture meaningful facts?
•Event Dispatching: How do we route events to interested handlers?
•Handler Design: How do we structure code that responds to events?
•Coupling Analysis: When does event-driven design reduce or increase complexity?
•Testability: How do we verify that the right events are raised and handled correctly?
•Debugging: How do we trace execution through an event-driven system?

The Anatomy of an Event-Driven System

Every event-driven system, regardless of scale, contains the same fundamental components. Understanding these components is essential before diving into implementation patterns.

Core Components:

Events: Immutable records of facts that occurred. These are the "messages" of the system.
Event Producers (Publishers): Components that create and emit events when significant state changes occur.
Event Dispatcher (Event Bus): The mechanism that receives events from producers and delivers them to consumers. This is the "router" of the system.
Event Consumers (Handlers/Subscribers): Components that receive events and perform actions in response.
Subscriptions: The registrations that connect consumers to specific event types they're interested in.

event-system-anatomy.ts
TypeScript
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
// ===== 1. EVENT: The immutable fact record =====
interface OrderPlacedEvent {
    readonly eventId: string;
    readonly eventType: "OrderPlaced";
    readonly occurredAt: Date;
    readonly payload: Readonly<{
        orderId: string;
        customerId: string;
        totalAmount: number;
    }>;
}
 
// ===== 2. EVENT PRODUCER: Emits events when things happen =====
class OrderService {
    constructor(private eventDispatcher: EventDispatcher) {}
    
    async placeOrder(customerId: string, items: OrderItem[]): Promise<Order> {
        // Business logic: create the order
        const order = new Order(customerId, items);
        await this.orderRepository.save(order);
        
        // PRODUCE an event announcing what happened
        const event: OrderPlacedEvent = {
            eventId: crypto.randomUUID(),
            eventType: "OrderPlaced",
            occurredAt: new Date(),
            payload: {
                orderId: order.id,
                customerId: order.customerId,
                totalAmount: order.calculateTotal(),
            },
        };
        
        // Dispatch to the event bus
        await this.eventDispatcher.dispatch(event);
        
        return order;
    }
}
 
// ===== 3. EVENT DISPATCHER: Routes events to handlers =====
interface EventHandler<T = DomainEvent> {
    handle(event: T): Promise<void>;
}
 
class EventDispatcher {
    private subscriptions: Map<string, EventHandler[]> = new Map();
    
    // Register a handler for an event type
    subscribe<T extends DomainEvent>(
        eventType: string,
        handler: EventHandler<T>
    ): void {
        const handlers = this.subscriptions.get(eventType) || [];
        this.subscriptions.set(eventType, [...handlers, handler]);
    }
    
    // Deliver event to all interested handlers
    async dispatch(event: DomainEvent): Promise<void> {
        const handlers = this.subscriptions.get(event.eventType) || [];
        
        await Promise.all(
            handlers.map(handler => handler.handle(event))
        );
    }
}
 
// ===== 4. EVENT CONSUMERS: React to events =====
class InventoryHandler implements EventHandler<OrderPlacedEvent> {
    async handle(event: OrderPlacedEvent): Promise<void> {
        // Reserve inventory for the order
        console.log(`Reserving inventory for order ${event.payload.orderId}`);
        await this.inventoryService.reserveForOrder(event.payload.orderId);
    }
}
 
class NotificationHandler implements EventHandler<OrderPlacedEvent> {
    async handle(event: OrderPlacedEvent): Promise<void> {
        // Send confirmation email
        console.log(`Sending confirmation for order ${event.payload.orderId}`);
        await this.emailService.sendOrderConfirmation(event.payload.customerId);
    }
}
 
class AnalyticsHandler implements EventHandler<OrderPlacedEvent> {
    async handle(event: OrderPlacedEvent): Promise<void> {
        // Track the order for analytics
        console.log(`Tracking order ${event.payload.orderId}`);
        await this.analytics.trackOrder(event.payload);
    }
}
 
// ===== 5. SUBSCRIPTIONS: Wire it all together =====
function configureEventHandlers(dispatcher: EventDispatcher): void {
    // Each subscription connects an event type to a handler
    dispatcher.subscribe("OrderPlaced", new InventoryHandler());
    dispatcher.subscribe("OrderPlaced", new NotificationHandler());
    dispatcher.subscribe("OrderPlaced", new AnalyticsHandler());
    
    // Easy to add more handlers without changing OrderService
    dispatcher.subscribe("OrderPlaced", new FraudDetectionHandler());
    dispatcher.subscribe("OrderPlaced", new LoyaltyPointsHandler());
}

Notice the Decoupling

Look at the OrderService class. It has no knowledge of InventoryHandler, NotificationHandler, or AnalyticsHandler. It doesn't import them, doesn't call them, doesn't even know they exist. All it does is announce 'OrderPlaced' and move on. The wiring happens elsewhere, at composition time, keeping the core business logic clean.

The Lifecycle of an Event

Understanding the complete lifecycle of an event helps you reason about event-driven systems. Every event goes through predictable phases from creation to completion.

Phase 1: Creation An event is instantiated when something significant happens. The producer creates an immutable event object with all relevant data.

Phase 2: Publication (Dispatch) The event is handed to the event dispatcher/bus. At this point, the producer's job is done.

Phase 3: Routing The dispatcher determines which handlers are subscribed to this event type. This is a lookup operation.

Phase 4: Delivery The event is delivered to each subscribed handler. Depending on the system, this might be synchronous (one at a time) or concurrent (all at once).

Phase 5: Processing Each handler receives the event and performs its specific logic. Handlers are independent—one handler's success or failure doesn't affect others.

Phase 6: Completion (or Failure) The event has been fully processed. In synchronous systems, the publisher may be notified. In asynchronous systems, completion is typically tracked separately (acknowledgments, completion logs).

┌─────────────────────────────────────────────────────────────────────┐
│                        EVENT LIFECYCLE                               │
├─────────────────────────────────────────────────────────────────────┤
│                                                                      │
│   ┌──────────┐    ┌──────────┐    ┌──────────┐    ┌──────────┐     │
│   │ PRODUCER │───▶│  EVENT   │───▶│DISPATCHER│───▶│ HANDLERS │     │
│   └──────────┘    └──────────┘    └──────────┘    └──────────┘     │
│        │               │               │               │            │
│   "Something      Immutable       Routes to          Process        │
│    happened!"      record        subscribers        event data      │
│        │               │               │               │            │
│   ┌────▼────┐    ┌────▼────┐    ┌────▼────┐    ┌────▼────┐        │
│   │ Create  │    │ Publish │    │ Deliver │    │ Handle  │        │
│   │  event  │ ──▶│   to    │ ──▶│   to    │ ──▶│  in     │        │
│   │ object  │    │  bus    │    │ each    │    │ each    │        │
│   └─────────┘    └─────────┘    │ handler │    │ handler │        │
│                                 └─────────┘    └─────────┘        │
│                                                                      │
└─────────────────────────────────────────────────────────────────────┘

Events Have No Return Values

Unlike method calls, events don't return values to the producer. If a handler needs to communicate results, it does so by publishing its own event. This is a key difference from request/response patterns and requires a shift in how you design interactions.

Real-World Analogy: The Office Building

Let's solidify our understanding with a detailed analogy. Imagine a large office building where different departments need to coordinate.

The Command-Oriented Office:

In this office, whenever something happens, the responsible person must personally notify everyone who needs to know:

HR hires a new employee and must walk to IT, Facilities, Finance, Security, and the employee's manager to inform them individually.
When IT provisions a laptop, they must walk back to HR to confirm.
When Facilities prepares a desk, they walk to HR to confirm.
If any department is busy or the person is at lunch, HR waits.

This office quickly becomes chaotic. HR spends more time walking around than hiring. Changes are difficult—if a new department needs to be notified, HR's checklist grows.

The Event-Driven Office:

Now imagine the office has a bulletin board system:

HR posts a notice: "New Employee Hired: John Smith, Engineering, Starting Monday"
Every department has signed up to receive relevant bulletin categories.
IT sees the notice and provisions a laptop.
Facilities sees the notice and prepares a desk.
Security sees the notice and creates an access badge.
The manager sees the notice and prepares onboarding materials.

HR posts once and is done. They don't know or care which departments are subscribed. If a new department (say, Parking) needs to be notified, they simply subscribe to "New Employee Hired" bulletins. HR's process doesn't change at all.

Office Building Analogy: Commands vs Events
Aspect	Command-Oriented Office	Event-Driven Office
Communication	Personal visits to each department	Post notice on bulletin board
HR's knowledge	Must know every department to notify	Knows only about the bulletin board
Adding new recipients	Change HR's checklist and training	New department subscribes to board
Department unavailable	HR waits or retries	Department catches up when available
Failure handling	HR must handle each failure case	Each department handles its own failures
Scalability	HR becomes bottleneck	Scales with number of boards, not HR's capacity

This analogy captures the essence of event-driven design's benefits:

Decoupling: HR doesn't depend on other departments' interfaces.
Extensibility: New subscribers don't require publisher changes.
Resilience: Failures are isolated; one department's problem doesn't block others.
Simplicity for publishers: Post once and forget.

Common Misconceptions About Event-Driven Design

Before we conclude, let's address common misconceptions that can lead to misuse or avoidance of event-driven patterns.

Misconceptions to Avoid

•"Event-driven means asynchronous." Events can be processed synchronously. The decoupling benefit exists regardless of timing. Async is an orthogonal concern, often added later for performance or reliability.
•"Event-driven means message queues." In-process event dispatching requires no external infrastructure. Kafka, RabbitMQ, etc., are tools for distributed event systems—not required for in-app events.
•"Events replace all method calls." Event-driven design is for significant state changes that might interest multiple parties. Not every interaction should be an event. Direct calls remain appropriate for focused, cohesive operations.
•"Event-driven is always better." Events add indirection, making code harder to trace. For simple, linear workflows with known recipients, direct calls may be clearer. Events shine when decoupling and extensibility matter.
•"Events are only for microservices." Events are valuable within a single monolith or library. They're about logical decoupling of components, not physical distribution of services.
•"Event-driven design is complex." The basic pattern—publish to a dispatcher, subscribe handlers—is straightforward. Complexity comes from the problems you solve (ordering, idempotency, durability), not the pattern itself.

Right Tool, Right Job

Event-driven design is a tool, not a religion. Use it where the benefits (decoupling, extensibility, resilience) outweigh the costs (indirection, complexity). Later modules will explore decision frameworks for when events are—and aren't—appropriate.

Summary: Understanding Event-Driven Design

We've established the foundational concepts of event-driven design. Let's consolidate what we've learned:

Key Takeaways

•Events are immutable records of facts. They describe what happened, using past tense, and cannot be changed after creation.
•Event-driven design inverts coupling. Publishers don't know their consumers; consumers subscribe independently.
•The mental shift is from commanding to announcing. Instead of telling components what to do, you declare what happened and let interested parties react.
•Synchronous vs asynchronous is orthogonal. Events can be processed immediately in-process or deferred via message queues—both are valid.
•Event-driven systems have consistent anatomy: Events, Producers, Dispatcher, Handlers, and Subscriptions.
•Events aren't always the right choice. They add indirection; use them when decoupling and extensibility benefits justify the cost.

What's next:

Now that we understand what events are, we need to distinguish them from a closely related but fundamentally different concept: commands. The next page explores the critical distinction between events and commands—a distinction that profoundly affects how you design inter-component communication and maintain clean architectural boundaries.

Page Complete

You now understand what event-driven design is, its fundamental components, and how it differs from traditional command-oriented communication. You're ready to explore the nuanced distinction between events and commands, which is essential for applying event-driven patterns correctly.