System Design (HLD)Event-Driven Fundamentals

Event-Driven Fundamentals

LevelIntermediate

Duration60 mins

TopicEvent-Driven Fundamentals

2 / 4

Events vs Commands

Two Messages, Two Paradigms

In distributed systems, we exchange messages between components. But not all messages are created equal. Two fundamentally different message types exist, each with distinct semantics, design implications, and appropriate use cases: Events and Commands.

The distinction may seem subtle—both are just messages, after all. But conflating them leads to architectural confusion, inappropriate coupling, and systems that are harder to reason about and maintain. Understanding this distinction is not pedantic—it's essential for building well-designed event-driven systems.

This page will give you an exhaustive understanding of events versus commands, when to use each, and how the choice shapes your entire system architecture.

What You Will Learn

By the end of this page, you will understand the semantic, grammatical, and design differences between events and commands, how each affects system coupling and ownership, common patterns for using both together, and how to make the right choice in ambiguous situations.

Defining the Distinction: Events vs Commands

Let's establish precise definitions:

Event: An immutable record of something that has already happened. Events describe facts about the past. They are notifications, not requests. The producer is informing, not asking.

Command: A request or instruction for an action to be performed. Commands express intent for something to happen in the future. The producer is asking, not informing.

The Grammatical Test:

A simple test: events are named in past tense; commands are named in imperative mood.

Events vs Commands: Naming Patterns
Type	Naming Pattern	Examples
Event	Past tense (what happened)	OrderPlaced, PaymentReceived, UserRegistered, ItemShipped
Command	Imperative (what to do)	PlaceOrder, ProcessPayment, RegisterUser, ShipItem

The Semantic Difference:

Beyond grammar, the semantic difference is profound:

Events describe reality. "OrderPlaced" means the order was placed. The recipient cannot reject this—it's a statement of fact about the past.
Commands express desire. "PlaceOrder" means someone wants an order to be placed. The recipient can accept, reject, or fail. It's a request, not a fact.

This distinction has cascading implications for system design, ownership, coupling, and failure handling.

The History Analogy

Events are like history. You can read about World War II, but you can't reject it or ask for it to be undone. It happened. Commands are like requests to your team. You can ask someone to deploy a fix, but they might refuse, fail, or need more information. The request expressing your wish is fundamentally different from describing what was done.

Ownership and Direction of Flow

One of the most important differences between events and commands is their ownership model and direction of coupling.

Events: Producer-Owned

•Owned by the producer — The team/service publishing the event defines its schema
•Outbound communication — "Here's what happened in my domain"
•Producer doesn't know consumers — Events are broadcast; consumers self-subscribe
•Consumer adapts to producer — Consumers work with whatever the producer publishes
•Many consumers possible — Single event, multiple independent reactions

Commands: Consumer-Owned

•Owned by the consumer — The team/service processing the command defines what it accepts
•Inbound communication — "Here's what I want you to do"
•Sender knows receiver — Commands are directed to a specific handler
•Sender adapts to receiver — Sender must know the receiver's expected format
•Single handler — One command, one responsible processor

Why Ownership Matters:

In a large organization, ownership determines who changes what. If the Order Service publishes OrderPlaced events, the Order team owns that event's schema. If someone wants new data in the event, they must request it from the Order team.

Conversely, if the Payment Service accepts ProcessPayment commands, the Payment team owns that command's schema. Anyone wanting to process payments must conform to what the Payment Service accepts.

This ownership model keeps boundaries clean. Events flow out from domain owners. Commands flow in to capability providers.

Direction of Coupling

With events, consumers couple to producers—they depend on the event schema the producer publishes. With commands, senders couple to receivers—they depend on the command format the receiver accepts. Understanding this coupling direction helps you reason about which teams need to coordinate during changes.

Failure Semantics: What Happens When Things Go Wrong

Events and commands have fundamentally different failure semantics, which affects how you design error handling, retries, and compensating actions.

Failure Handling: Events vs Commands
Scenario	Event Behavior	Command Behavior
Message published	Fact recorded—cannot be 'undone'	Request submitted—outcome uncertain
Consumer/handler unavailable	Event buffered; processed later	Command may timeout; sender must decide
Processing fails	Retry is safe (event is still true)	Retry may be unsafe (side effects already occurred?)
Validation fails	What does this mean? Event is fact—it happened	Command rejected; sender notified of failure
Business rules reject	Events aren't rejected—they describe reality	Command rejected; compensating action needed
Need to undo	Publish compensating event (e.g., OrderCancelled)	Rollback or compensating command

The Rejection Problem:

Consider a subtle but important question: Can you reject an event?

In the strict sense, no. The event describes something that already happened. If you receive PaymentReceived, you cannot reject it—the payment was received. You might choose to take no action, but the event remains true.

With commands, rejection is expected. If you receive ProcessPayment and the account has insufficient funds, you reject it. The payment was not processed. The command failed, and the sender needs to know.

Compensating Events:

Because events cannot be undone (they're historical facts), we use compensating events to record subsequent state changes:

OrderPlaced followed by OrderCancelled
PaymentReceived followed by PaymentRefunded
UserRegistered followed by UserDeactivated

The original event remains true—the order was placed. The compensating event records that it was later cancelled.

Idempotency Requirements Differ

Because events describe facts, processing the same event twice should be safe—the fact hasn't changed. Consumers MUST be idempotent. Commands present a harder problem: did the previous attempt succeed or fail? Did it have side effects? Command handlers need careful idempotency design to avoid duplicating effects.

Temporal Semantics: Past, Present, and Future

The temporal nature of events and commands creates important design implications:

Events: Statements About The Past

•Timestamp is meaningful — Events record when something happened, not when they were processed
•Order matters for history — Events form a sequence that tells a story (added to cart → placed order → paid → shipped)
•Events are replayable — Processing the entire event log should reconstruct current state
•Late arrival is expected — Events may be processed long after they occurred; systems must handle this
•Events don't expire — An event from yesterday is still true today; it describes historical fact

Commands: Requests for Future Action

•Timestamp indicates when issued — When was the request made?
•Order may or may not matter — Depends on whether commands are independent or interdependent
•Commands may be invalid over time — A request to reserve a seat may fail if the seat is no longer available
•Commands may expire — A request issued yesterday may no longer be relevant today
•Timeliness can be critical — Some commands must be processed within a deadline

The Time Machine Test

Here's a useful thought experiment: If you replay all your messages from the beginning of time, what happens? With events, you should be able to reconstruct current state—events form a complete history. With commands, replay would cause chaos—you'd re-execute all requests, duplicating side effects. This is why event sourcing works but 'command sourcing' doesn't.

Coupling Implications: How Each Affects System Design

The choice between events and commands has profound implications for how tightly or loosely coupled your system becomes.

Events Enable Loose Coupling:

When you publish events, you don't know (or care) who consumes them. The Order Service announces OrderPlaced without knowing that:

The Email Service will send a confirmation
The Inventory Service will reserve stock
The Analytics Service will update dashboards
The Fraud Detection Service will analyze the order

Each consumer independently subscribes and reacts. Adding a new consumer (say, a Loyalty Service) requires zero changes to the Order Service.

Commands Create Explicit Coupling:

When you send a command, you explicitly know the receiver. The Checkout Service sending ProcessPayment knows:

Exactly which service handles payments
The expected format of the command
How to interpret success/failure responses

This is tighter coupling, but it's intentional. For critical actions where you need confirmation and control, explicit coupling is appropriate.

Coupling Characteristics
Dimension	Events	Commands
Knowledge of receiver	None—publish to topic	Explicit—send to specific handler
Adding new reactions	Consumer subscribes; no producer changes	New integration requires sender changes
Removing reactions	Consumer unsubscribes; no producer changes	Sender may need to handle absence
Schema changes	Consumers must adapt to producer	Sender must adapt to handler
Testing in isolation	Easy—publish events, verify output	Requires handler or mock

Loose Coupling Isn't Always Better

While loose coupling is often desirable, it's not universally better. Commands provide clear responsibility, explicit failure handling, and guaranteed delivery acknowledgment. For critical financial transactions, legal actions, or anything requiring confirmation, command-style explicit coupling may be more appropriate than fire-and-forget events.

Fan-Out vs Point-to-Point Communication

The structural patterns enabled by events and commands differ significantly:

Events: Fan-Out Pattern

•One event, many consumers
•Consumers process independently
•No coordination between consumers
•Great for notifications, triggers
•Scaling: each consumer independently
•Example: OrderPlaced → Email + Inventory + Analytics

Commands: Point-to-Point Pattern

•One command, one handler
•Clear responsibility assignment
•Handler owns the outcome
•Great for actions, requests
•Scaling: competing consumers
•Example: ProcessPayment → Payment Service

Fan-Out Details:

With event fan-out, each consumer sees every event and decides independently how to react (or not). This creates maximum flexibility:

OrderPlaced (event)
    ├── Email Service → sends confirmation email
    ├── Inventory Service → reserves inventory  
    ├── Analytics Service → updates metrics
    ├── Fraud Service → runs fraud check
    └── [Future: Loyalty Service → awards points]

The Order Service publishes once. The broker delivers to all subscribers. Each consumer is isolated—a bug in the Fraud Service doesn't affect email delivery.

Point-to-Point Details:

With commands, you have explicit routing to a specific handler. This provides:

Clear ownership: One service is responsible for the outcome
Response capability: Handler can respond with success/failure/result
Backpressure: Sender knows if handler is overwhelmed

For work distribution (like processing payments), you might have multiple handler instances, but only one handles any given command (competing consumers pattern).

Decision Framework: When to Use Events vs Commands

With a thorough understanding of the differences, here's a practical decision framework:

Events vs Commands Decision Matrix
Scenario	Use Event	Use Command
Something happened that others might care about	✅ Announce it
Need to notify multiple independent systems	✅ Fan-out
Want to record history for audit/replay	✅ Events form immutable log
Producer shouldn't know/care about consumers	✅ Loose coupling
Need to request a specific action		✅ Direct request
Need confirmation of success/failure		✅ Response expected
Action has a single responsible owner		✅ Clear responsibility
Need synchronous-style semantics over async		✅ Request-response pattern

Hybrid Patterns:

In practice, systems often use both. A common pattern:

User interaction triggers a command: "Place Order"
Command handler performs action: Validates, persists order
Action completion produces an event: "OrderPlaced"
Event triggers downstream reactions: Email, inventory, analytics

This combines the explicit control of commands (for the critical action) with the loose coupling of events (for downstream reactions).

The Litmus Test

Ask yourself: Am I describing something that happened, or asking for something to happen? If it's past-tense fact, it's an event. If it's an imperative request, it's a command. The grammar usually reveals the truth.

Common Mistakes and Anti-Patterns

Understanding the distinction helps you avoid common architectural mistakes:

Anti-Patterns to Avoid

•Command Disguised as Event — Publishing "SendEmail" as an event. This is a command (imperative, single handler). Name it correctly and use point-to-point delivery.
•Event Disguised as Command — Sending "OrderPlaced" to a queue expecting a response. Events don't have responses—they're announcements. Use event streaming, not request-response.
•Rejecting Events — Trying to 'reject' an event because the consumer disagrees. Events are facts; you can ignore them or produce compensating events, but you can't reject reality.
•Expecting Event Acknowledgment — Waiting for confirmation that an event was processed. Events are fire-and-forget from the producer's perspective. If you need acknowledgment, use commands.
•Overloading Event with Command Intent — Publishing "UserShouldBeNotified" (command) instead of "UserLoggedIn" (event). Events describe what happened; they don't prescribe what should happen next.
•Commands Without Clear Handler — Sending a command without knowing who handles it. Commands require explicit routing to a responsible service.

The Naming Test Catches Most Mistakes

If your 'event' starts with a verb like 'Send', 'Process', 'Create', 'Update'—it's probably a command in disguise. Events are named with past-tense verbs: 'Sent', 'Processed', 'Created', 'Updated'. Get the grammar right, and the design usually follows.

Real-World Example: E-Commerce Order Flow

Let's see how events and commands work together in a realistic e-commerce order flow:

Order Flow: Commands and Events

Pseudo-Flow

// USER ACTION: Customer clicks "Place Order"
 
// ─────────────────────────────────────────────────────────────────
// STEP 1: COMMAND - PlaceOrder (explicit request to order service)
// ─────────────────────────────────────────────────────────────────
COMMAND: PlaceOrder {
    customerId: "cust_123",
    items: [...],
    shippingAddress: {...},
    paymentMethod: "card_xyz"
}
→ Sent to: Order Service (single handler)
→ Expected: Success/Failure response
 
// Order Service validates, creates order, returns orderId
RESPONSE: { success: true, orderId: "ord_456" }
 
// ─────────────────────────────────────────────────────────────────
// STEP 2: EVENT - OrderPlaced (broadcast announcement)
// ─────────────────────────────────────────────────────────────────
EVENT: OrderPlaced {
    orderId: "ord_456",
    customerId: "cust_123",
    items: [...],
    totalAmount: 149.99,
    timestamp: "2025-01-08T10:30:00Z"
}
→ Published to: "order-events" topic
→ Consumers: Email, Inventory, Analytics, Fraud (all independent)
 
// ─────────────────────────────────────────────────────────────────
// STEP 3: COMMAND - ProcessPayment (explicit request to payment service)
// ─────────────────────────────────────────────────────────────────
COMMAND: ProcessPayment {
    orderId: "ord_456",
    amount: 149.99,
    paymentMethod: "card_xyz"
}
→ Sent to: Payment Service (single handler)
→ Expected: Success/Failure response
 
// Payment Service charges card, returns result
RESPONSE: { success: true, paymentId: "pay_789" }
 
// ─────────────────────────────────────────────────────────────────
// STEP 4: EVENT - PaymentCompleted (broadcast announcement)
// ─────────────────────────────────────────────────────────────────
EVENT: PaymentCompleted {
    paymentId: "pay_789",
    orderId: "ord_456",
    amount: 149.99,
    method: "credit_card",
    timestamp: "2025-01-08T10:30:05Z"
}
→ Published to: "payment-events" topic
→ Consumers: Order Service, Email Service, Accounting, Analytics
 
// ─────────────────────────────────────────────────────────────────
// STEP 5: COMMAND - ShipOrder (explicit request to fulfillment)
// ─────────────────────────────────────────────────────────────────
// Triggered by Order Service upon receiving PaymentCompleted
COMMAND: ShipOrder {
    orderId: "ord_456",
    items: [...],
    shippingAddress: {...}
}
→ Sent to: Fulfillment Service
→ Expected: Success/Failure/TrackingNumber
 
// ─────────────────────────────────────────────────────────────────
// STEP 6: EVENT - OrderShipped (broadcast announcement)
// ─────────────────────────────────────────────────────────────────
EVENT: OrderShipped {
    orderId: "ord_456",
    trackingNumber: "TRK_123456",
    carrier: "FedEx",
    estimatedDelivery: "2025-01-12",
    timestamp: "2025-01-08T14:00:00Z"
}
→ Published to: "fulfillment-events" topic
→ Consumers: Email Service, Customer App, Analytics

Pattern Analysis:

Notice the rhythm: Command → Event → Command → Event

Commands for critical actions requiring confirmation (placing order, processing payment, shipping)
Events for broadcasting what happened after each action completes

This hybrid approach gives you:

Explicit control and failure handling for critical actions (commands)
Loose coupling for reactions and notifications (events)
Full audit trail of what happened (event history)
Clear ownership and responsibility (command handlers)

Summary: Events vs Commands

The distinction between events and commands is fundamental to well-designed event-driven systems. Let's consolidate the key insights:

Key Takeaways

•Events describe the past; commands request the future — Events are past-tense facts; commands are imperative requests.
•Events are producer-owned; commands are consumer-owned — Ownership determines who controls the schema.
•Events enable loose coupling; commands create explicit coupling — Choose based on coupling requirements.
•Events fan out; commands are point-to-point — One event, many consumers vs. one command, one handler.
•Events cannot be rejected; commands can fail — Events are facts; commands are requests that may not succeed.
•Use both in hybrid patterns — Commands for critical actions with confirmation; events for broadcasting outcomes.
•Naming reveals intent — Past tense = event. Imperative = command. Get the grammar right.

What's Next:

Now that we understand the fundamental distinction between events and commands, we'll explore the entities that send and receive these messages. The next page examines Producers and Consumers—the components that create events and react to them, including their design patterns, responsibilities, and best practices.

Page Complete

You now have a deep understanding of the difference between events and commands—the foundational distinction that shapes event-driven system design. This knowledge will guide your architectural decisions about when to announce versus when to request, and how to structure communication between services.

2 / 4

Loading learning content...

System Design (HLD)Event-Driven Fundamentals

Event-Driven Fundamentals

LevelIntermediate

Duration60 mins

TopicEvent-Driven Fundamentals

2 / 4

Events vs Commands

Two Messages, Two Paradigms

This page will give you an exhaustive understanding of events versus commands, when to use each, and how the choice shapes your entire system architecture.

What You Will Learn

Defining the Distinction: Events vs Commands

Let's establish precise definitions:

Event: An immutable record of something that has already happened. Events describe facts about the past. They are notifications, not requests. The producer is informing, not asking.

Command: A request or instruction for an action to be performed. Commands express intent for something to happen in the future. The producer is asking, not informing.

The Grammatical Test:

A simple test: events are named in past tense; commands are named in imperative mood.

Events vs Commands: Naming Patterns
Type	Naming Pattern	Examples
Event	Past tense (what happened)	OrderPlaced, PaymentReceived, UserRegistered, ItemShipped
Command	Imperative (what to do)	PlaceOrder, ProcessPayment, RegisterUser, ShipItem

The Semantic Difference:

Beyond grammar, the semantic difference is profound:

Events describe reality. "OrderPlaced" means the order was placed. The recipient cannot reject this—it's a statement of fact about the past.
Commands express desire. "PlaceOrder" means someone wants an order to be placed. The recipient can accept, reject, or fail. It's a request, not a fact.

This distinction has cascading implications for system design, ownership, coupling, and failure handling.

The History Analogy

Ownership and Direction of Flow

One of the most important differences between events and commands is their ownership model and direction of coupling.

Events: Producer-Owned

•Owned by the producer — The team/service publishing the event defines its schema
•Outbound communication — "Here's what happened in my domain"
•Producer doesn't know consumers — Events are broadcast; consumers self-subscribe
•Consumer adapts to producer — Consumers work with whatever the producer publishes
•Many consumers possible — Single event, multiple independent reactions

Commands: Consumer-Owned

•Owned by the consumer — The team/service processing the command defines what it accepts
•Inbound communication — "Here's what I want you to do"
•Sender knows receiver — Commands are directed to a specific handler
•Sender adapts to receiver — Sender must know the receiver's expected format
•Single handler — One command, one responsible processor

Why Ownership Matters:

Conversely, if the Payment Service accepts ProcessPayment commands, the Payment team owns that command's schema. Anyone wanting to process payments must conform to what the Payment Service accepts.

This ownership model keeps boundaries clean. Events flow out from domain owners. Commands flow in to capability providers.

Direction of Coupling

Failure Semantics: What Happens When Things Go Wrong

Events and commands have fundamentally different failure semantics, which affects how you design error handling, retries, and compensating actions.

Failure Handling: Events vs Commands
Scenario	Event Behavior	Command Behavior
Message published	Fact recorded—cannot be 'undone'	Request submitted—outcome uncertain
Consumer/handler unavailable	Event buffered; processed later	Command may timeout; sender must decide
Processing fails	Retry is safe (event is still true)	Retry may be unsafe (side effects already occurred?)
Validation fails	What does this mean? Event is fact—it happened	Command rejected; sender notified of failure
Business rules reject	Events aren't rejected—they describe reality	Command rejected; compensating action needed
Need to undo	Publish compensating event (e.g., OrderCancelled)	Rollback or compensating command

The Rejection Problem:

Consider a subtle but important question: Can you reject an event?

Compensating Events:

Because events cannot be undone (they're historical facts), we use compensating events to record subsequent state changes:

OrderPlaced followed by OrderCancelled
PaymentReceived followed by PaymentRefunded
UserRegistered followed by UserDeactivated

The original event remains true—the order was placed. The compensating event records that it was later cancelled.

Idempotency Requirements Differ

Temporal Semantics: Past, Present, and Future

The temporal nature of events and commands creates important design implications:

Events: Statements About The Past

•Timestamp is meaningful — Events record when something happened, not when they were processed
•Order matters for history — Events form a sequence that tells a story (added to cart → placed order → paid → shipped)
•Events are replayable — Processing the entire event log should reconstruct current state
•Late arrival is expected — Events may be processed long after they occurred; systems must handle this
•Events don't expire — An event from yesterday is still true today; it describes historical fact

Commands: Requests for Future Action

•Timestamp indicates when issued — When was the request made?
•Order may or may not matter — Depends on whether commands are independent or interdependent
•Commands may be invalid over time — A request to reserve a seat may fail if the seat is no longer available
•Commands may expire — A request issued yesterday may no longer be relevant today
•Timeliness can be critical — Some commands must be processed within a deadline

The Time Machine Test

Coupling Implications: How Each Affects System Design

The choice between events and commands has profound implications for how tightly or loosely coupled your system becomes.

Events Enable Loose Coupling:

When you publish events, you don't know (or care) who consumes them. The Order Service announces OrderPlaced without knowing that:

The Email Service will send a confirmation
The Inventory Service will reserve stock
The Analytics Service will update dashboards
The Fraud Detection Service will analyze the order

Each consumer independently subscribes and reacts. Adding a new consumer (say, a Loyalty Service) requires zero changes to the Order Service.

Commands Create Explicit Coupling:

When you send a command, you explicitly know the receiver. The Checkout Service sending ProcessPayment knows:

Exactly which service handles payments
The expected format of the command
How to interpret success/failure responses

This is tighter coupling, but it's intentional. For critical actions where you need confirmation and control, explicit coupling is appropriate.

Coupling Characteristics
Dimension	Events	Commands
Knowledge of receiver	None—publish to topic	Explicit—send to specific handler
Adding new reactions	Consumer subscribes; no producer changes	New integration requires sender changes
Removing reactions	Consumer unsubscribes; no producer changes	Sender may need to handle absence
Schema changes	Consumers must adapt to producer	Sender must adapt to handler
Testing in isolation	Easy—publish events, verify output	Requires handler or mock

Loose Coupling Isn't Always Better

Fan-Out vs Point-to-Point Communication

The structural patterns enabled by events and commands differ significantly:

Events: Fan-Out Pattern

•One event, many consumers
•Consumers process independently
•No coordination between consumers
•Great for notifications, triggers
•Scaling: each consumer independently
•Example: OrderPlaced → Email + Inventory + Analytics

Commands: Point-to-Point Pattern

•One command, one handler
•Clear responsibility assignment
•Handler owns the outcome
•Great for actions, requests
•Scaling: competing consumers
•Example: ProcessPayment → Payment Service

Fan-Out Details:

With event fan-out, each consumer sees every event and decides independently how to react (or not). This creates maximum flexibility:

OrderPlaced (event)
    ├── Email Service → sends confirmation email
    ├── Inventory Service → reserves inventory  
    ├── Analytics Service → updates metrics
    ├── Fraud Service → runs fraud check
    └── [Future: Loyalty Service → awards points]

The Order Service publishes once. The broker delivers to all subscribers. Each consumer is isolated—a bug in the Fraud Service doesn't affect email delivery.

Point-to-Point Details:

With commands, you have explicit routing to a specific handler. This provides:

Clear ownership: One service is responsible for the outcome
Response capability: Handler can respond with success/failure/result
Backpressure: Sender knows if handler is overwhelmed

For work distribution (like processing payments), you might have multiple handler instances, but only one handles any given command (competing consumers pattern).

Decision Framework: When to Use Events vs Commands

With a thorough understanding of the differences, here's a practical decision framework:

Events vs Commands Decision Matrix
Scenario	Use Event	Use Command
Something happened that others might care about	✅ Announce it
Need to notify multiple independent systems	✅ Fan-out
Want to record history for audit/replay	✅ Events form immutable log
Producer shouldn't know/care about consumers	✅ Loose coupling
Need to request a specific action		✅ Direct request
Need confirmation of success/failure		✅ Response expected
Action has a single responsible owner		✅ Clear responsibility
Need synchronous-style semantics over async		✅ Request-response pattern

Hybrid Patterns:

In practice, systems often use both. A common pattern:

User interaction triggers a command: "Place Order"
Command handler performs action: Validates, persists order
Action completion produces an event: "OrderPlaced"
Event triggers downstream reactions: Email, inventory, analytics

This combines the explicit control of commands (for the critical action) with the loose coupling of events (for downstream reactions).

The Litmus Test

Common Mistakes and Anti-Patterns

Understanding the distinction helps you avoid common architectural mistakes:

Anti-Patterns to Avoid

•Command Disguised as Event — Publishing "SendEmail" as an event. This is a command (imperative, single handler). Name it correctly and use point-to-point delivery.
•Event Disguised as Command — Sending "OrderPlaced" to a queue expecting a response. Events don't have responses—they're announcements. Use event streaming, not request-response.
•Rejecting Events — Trying to 'reject' an event because the consumer disagrees. Events are facts; you can ignore them or produce compensating events, but you can't reject reality.
•Expecting Event Acknowledgment — Waiting for confirmation that an event was processed. Events are fire-and-forget from the producer's perspective. If you need acknowledgment, use commands.
•Overloading Event with Command Intent — Publishing "UserShouldBeNotified" (command) instead of "UserLoggedIn" (event). Events describe what happened; they don't prescribe what should happen next.
•Commands Without Clear Handler — Sending a command without knowing who handles it. Commands require explicit routing to a responsible service.

The Naming Test Catches Most Mistakes

Real-World Example: E-Commerce Order Flow

Let's see how events and commands work together in a realistic e-commerce order flow:

Order Flow: Commands and Events

Pseudo-Flow

// USER ACTION: Customer clicks "Place Order"
 
// ─────────────────────────────────────────────────────────────────
// STEP 1: COMMAND - PlaceOrder (explicit request to order service)
// ─────────────────────────────────────────────────────────────────
COMMAND: PlaceOrder {
    customerId: "cust_123",
    items: [...],
    shippingAddress: {...},
    paymentMethod: "card_xyz"
}
→ Sent to: Order Service (single handler)
→ Expected: Success/Failure response
 
// Order Service validates, creates order, returns orderId
RESPONSE: { success: true, orderId: "ord_456" }
 
// ─────────────────────────────────────────────────────────────────
// STEP 2: EVENT - OrderPlaced (broadcast announcement)
// ─────────────────────────────────────────────────────────────────
EVENT: OrderPlaced {
    orderId: "ord_456",
    customerId: "cust_123",
    items: [...],
    totalAmount: 149.99,
    timestamp: "2025-01-08T10:30:00Z"
}
→ Published to: "order-events" topic
→ Consumers: Email, Inventory, Analytics, Fraud (all independent)
 
// ─────────────────────────────────────────────────────────────────
// STEP 3: COMMAND - ProcessPayment (explicit request to payment service)
// ─────────────────────────────────────────────────────────────────
COMMAND: ProcessPayment {
    orderId: "ord_456",
    amount: 149.99,
    paymentMethod: "card_xyz"
}
→ Sent to: Payment Service (single handler)
→ Expected: Success/Failure response
 
// Payment Service charges card, returns result
RESPONSE: { success: true, paymentId: "pay_789" }
 
// ─────────────────────────────────────────────────────────────────
// STEP 4: EVENT - PaymentCompleted (broadcast announcement)
// ─────────────────────────────────────────────────────────────────
EVENT: PaymentCompleted {
    paymentId: "pay_789",
    orderId: "ord_456",
    amount: 149.99,
    method: "credit_card",
    timestamp: "2025-01-08T10:30:05Z"
}
→ Published to: "payment-events" topic
→ Consumers: Order Service, Email Service, Accounting, Analytics
 
// ─────────────────────────────────────────────────────────────────
// STEP 5: COMMAND - ShipOrder (explicit request to fulfillment)
// ─────────────────────────────────────────────────────────────────
// Triggered by Order Service upon receiving PaymentCompleted
COMMAND: ShipOrder {
    orderId: "ord_456",
    items: [...],
    shippingAddress: {...}
}
→ Sent to: Fulfillment Service
→ Expected: Success/Failure/TrackingNumber
 
// ─────────────────────────────────────────────────────────────────
// STEP 6: EVENT - OrderShipped (broadcast announcement)
// ─────────────────────────────────────────────────────────────────
EVENT: OrderShipped {
    orderId: "ord_456",
    trackingNumber: "TRK_123456",
    carrier: "FedEx",
    estimatedDelivery: "2025-01-12",
    timestamp: "2025-01-08T14:00:00Z"
}
→ Published to: "fulfillment-events" topic
→ Consumers: Email Service, Customer App, Analytics

Pattern Analysis:

Notice the rhythm: Command → Event → Command → Event

Commands for critical actions requiring confirmation (placing order, processing payment, shipping)
Events for broadcasting what happened after each action completes

This hybrid approach gives you:

Explicit control and failure handling for critical actions (commands)
Loose coupling for reactions and notifications (events)
Full audit trail of what happened (event history)
Clear ownership and responsibility (command handlers)

Summary: Events vs Commands

The distinction between events and commands is fundamental to well-designed event-driven systems. Let's consolidate the key insights:

Key Takeaways

•Events describe the past; commands request the future — Events are past-tense facts; commands are imperative requests.
•Events are producer-owned; commands are consumer-owned — Ownership determines who controls the schema.
•Events enable loose coupling; commands create explicit coupling — Choose based on coupling requirements.
•Events fan out; commands are point-to-point — One event, many consumers vs. one command, one handler.
•Events cannot be rejected; commands can fail — Events are facts; commands are requests that may not succeed.
•Use both in hybrid patterns — Commands for critical actions with confirmation; events for broadcasting outcomes.
•Naming reveals intent — Past tense = event. Imperative = command. Get the grammar right.

What's Next:

Page Complete

2 / 4