Event-Driven Architecture: A Complete Guide with Examples in 11 Programming Languages

Event-Driven Architecture — EDA — is a software design paradigm in which components communicate by producing and consuming events rather than calling each other directly. An event is an immutable record of something that happened: an order was placed, a payment was processed, a user registered, a sensor reading exceeded a threshold. The component that detects or causes the occurrence publishes the event. Any number of other components — none of which the publisher needs to know about — react to it independently.

EDA inverts the communication model of traditional request-response systems. In a direct call, the caller knows the callee, waits for a response, and couples its success to the callee's availability. In an event-driven system, the publisher knows nothing about its consumers. It fires the event and continues. Consumers subscribe independently and react on their own schedule. The result is a system where components are loosely coupled, independently scalable, and capable of handling complex workflows without direct dependency chains.

In this comprehensive guide, we'll explore Event-Driven Architecture with real-world examples in Python, TypeScript, Java, JavaScript, C#, PHP, Go, Rust, Dart, Swift, and Kotlin — complete with language-specific best practices, common pitfalls, and the patterns that produce resilient, scalable event-driven systems.

Table of Contents

• What is Event-Driven Architecture?
• Why Use Event-Driven Architecture?
• Event-Driven Architecture Comparison
• Event-Driven Architecture Explained
• Architecture Diagram
• Beginner-Friendly Example
• Production-Ready Example
• Real-World Use Cases
• Language-Specific Mistakes and Anti-Patterns
• Frequently Asked Questions
• Key Takeaways

What is Event-Driven Architecture?

An event-driven system has three fundamental participants:

Event producers detect or cause something to happen and publish an event describing it. The producer's job ends the moment the event is published. It has no knowledge of what happens next, how many consumers exist, or whether any consumer is currently running.

Events are immutable value objects that describe what happened — not instructions for what should happen next. An event says "OrderPlaced with ID ORD-001 for $49.99 at 14:32 UTC" — it does not say "send a confirmation email" or "update the inventory." What to do with the event is entirely the consumer's decision.

Event consumers (subscribers, listeners, handlers) subscribe to events of interest and react to them. Multiple consumers can react to the same event independently. A new consumer can be added without modifying the producer. A consumer can be removed without affecting the producer or other consumers.

Between producers and consumers sits the event broker — the infrastructure that receives events from producers and delivers them to subscribers. The broker may be in-process (a simple list of callbacks), in-memory (a channel or queue), or distributed (Kafka, RabbitMQ, AWS EventBridge, Google Pub/Sub). The broker is what makes producers and consumers genuinely independent: a producer publishes to the broker; consumers subscribe to the broker; neither knows about the other.

The key characteristic of EDA is temporal decoupling: the producer publishes when something happens; the consumer reacts when it is ready. These are not required to happen at the same time. A message broker persists events until consumers are ready to process them, enabling asynchronous workflows across independently-scaled services.

Why Use Event-Driven Architecture?

EDA addresses real limitations of synchronous request-response architectures:

1. Loose coupling: Producers and consumers have no compile-time or runtime dependency on each other. Adding a new consumer requires no modification to the producer. The email service, the inventory service, and the analytics service all react to OrderPlaced — and the order service knows none of them.

2. Independent scalability: Because producers and consumers are decoupled, each can scale independently. If email processing is the bottleneck, scale the email consumer — not the order service. Queue-based brokers absorb traffic spikes, allowing consumers to process at their own pace.

3. Resilience: When a consumer fails, the broker retains unprocessed events. When the consumer recovers, it processes the backlog. A direct call to a failed service propagates the failure to the caller; an event published to a broker survives the consumer's failure.

4. Extensibility: Adding new behavior to an event requires adding a new consumer, not modifying existing code. The open/closed principle applied at the architecture level: the system is open for extension (add consumers) but closed for modification (don't touch existing producers or consumers).

5. Audit trail: Every event is a record of something that happened at a specific time. The event log is a natural audit trail — a complete history of the system's state changes.

6. Polyglot compatibility: Producers and consumers communicate through events (messages), not through shared code. The order service can be in Python; the email service in Go; the analytics service in TypeScript. They share an event schema, not a language or framework.

7. Real-time reactivity: Events enable real-time responses to system state changes — dashboards, notifications, streaming analytics — without polling.

Event-Driven Architecture Comparison

EDA vs. Request-Response: Request-response (REST API, gRPC) is synchronous and point-to-point — the caller knows the callee, waits for a response, and fails if the callee is unavailable. EDA is asynchronous and broadcast — the producer publishes without knowing the consumers, which react independently. Use request-response for queries that need an immediate answer; use EDA for workflows where the producer should not wait for downstream processing.

EDA vs. Message Queue: A message queue delivers a message to exactly one consumer (competing consumers model). EDA (pub/sub) delivers an event to all subscribers. A queue is for task distribution — one worker processes each job. A pub/sub event broker is for fan-out — every interested party receives every event. Most production EDA systems use both: pub/sub topics for event distribution, queues per consumer for reliable processing.

EDA vs. Observer Pattern: The Observer Pattern is the in-process, object-oriented antecedent to EDA. An observable object maintains a list of observers and notifies them synchronously. EDA applies the same principle across process and network boundaries, with a broker instead of an in-memory list, and asynchronous delivery instead of synchronous callbacks. Observer is EDA within a single process; EDA is Observer across a distributed system.

EDA vs. CQRS: CQRS (Command Query Responsibility Segregation) separates write operations (commands) from read operations (queries). EDA is the most natural implementation mechanism for CQRS — commands produce events that update read models. They are complementary: CQRS defines the separation; EDA implements the communication between the command side and the read side.

Event-Driven Architecture Explained

Core EDA Patterns

Simple Event Notification: A producer publishes an event; consumers are notified. The event contains only a reference (an ID) to the changed data. Consumers query the producer's API for details if needed. Simple, but requires consumers to make a follow-up call.

Event-Carried State Transfer: The event contains all the data consumers need. No follow-up query required. Consumers are truly independent — they never call back to the producer. The trade-off is larger event payloads and the risk that consumers see a snapshot of data that may change.

Event Sourcing: The system's state is not stored as a current value in a database; it is derived by replaying the full sequence of events. Every state change is an event; the current state is the result of applying all events in order. Provides a complete audit log and the ability to reconstruct state at any point in time.

CQRS with Events: Write operations produce events; read models (projections) consume those events to maintain optimized read-side data structures. Allows read and write sides to be optimized and scaled independently.

Event Design Principles

Events describe facts, not intentions: OrderPlaced is a fact about what happened. PlaceOrder is a command (instruction). Events are past tense. A consumer decides what to do in response; the producer makes no assumptions.

Events are immutable: Once published, an event cannot be changed. If a correction is needed, a new corrective event is published. The event log is append-only.

Events carry sufficient context: An event should contain enough information for consumers to act without requiring additional queries — or at minimum, enough to identify what to query. At minimum: event type, timestamp, unique ID, and the ID of the entity that changed.

Events are versioned: Event schemas evolve. A versioning strategy (schema registry, envelope versioning, content negotiation) ensures producers and consumers can evolve independently without breaking each other.

Event Schema

A well-structured event envelope:

{
  "eventId":   "evt_01J8XK9M...",
  "eventType": "order.placed",
  "version":   "1.0",
  "timestamp": "2024-10-15T14:32:00Z",
  "source":    "order-service",
  "payload": {
    "orderId":    "ORD-001",
    "customerId": "CUST-123",
    "totalAmount": 49.99,
    "currency":   "USD",
    "items": [
      { "sku": "SKU-001", "quantity": 2, "unitPrice": 24.99 }
    ]
  }
}

Delivery Guarantees

At-most-once: Events may be lost but are never delivered twice. Suitable for metrics and non-critical notifications where occasional loss is acceptable.

At-least-once: Events are never lost but may be delivered more than once. Consumers must be idempotent — processing the same event twice produces the same result as processing it once. This is the most common guarantee in production systems.

Exactly-once: Events are delivered precisely once. The hardest guarantee to achieve in distributed systems; requires transactional coordination between the broker and the consumer's state store.

Consumer Patterns

Competing consumers: Multiple instances of the same consumer share a queue, each processing different messages. Enables horizontal scaling of consumer processing.

Fan-out: One event is delivered to multiple independent consumer groups, each maintaining their own position in the event stream. Each consumer group processes every event independently.

Dead Letter Queue (DLQ): Events that repeatedly fail to be processed are moved to a DLQ for manual inspection, alerting, or reprocessing. Prevents a single bad event from blocking an entire queue.

Architecture Diagram

Beginner-Friendly Example

The clearest EDA illustration: an e-commerce order placement that triggers multiple downstream actions — email confirmation, inventory reservation, and analytics tracking. The non-EDA approach calls each downstream service directly, coupling them all. The EDA approach publishes one event; each service reacts independently.

from __future__ import annotations
from dataclasses import dataclass, field
from datetime import datetime, timezone
from typing import Callable, Any
from decimal import Decimal
import uuid


# ════════════════════════════════════════════════════════════════
# WITHOUT EDA — Direct calls; tight coupling, all-or-nothing
# ════════════════════════════════════════════════════════════════

class OrderServiceNonEDA:
    def place_order(self, customer_id: str, amount: Decimal) -> str:
        order_id = str(uuid.uuid4())

        # Persists order
        print(f"[DB] Order {order_id} saved")

        # Direct call to Email Service — if it fails, the whole order fails
        self._send_confirmation_email(customer_id, order_id, amount)

        # Direct call to Inventory Service — must know about it
        self._reserve_inventory(order_id)

        # Direct call to Analytics — must know about it too
        self._track_order_placed(order_id, amount)

        return order_id

    def _send_confirmation_email(self, customer_id, order_id, amount):
        print(f"[Email] Confirmation sent to {customer_id} for order {order_id}")

    def _reserve_inventory(self, order_id):
        print(f"[Inventory] Reserved for order {order_id}")

    def _track_order_placed(self, order_id, amount):
        print(f"[Analytics] Tracked order {order_id}: ${amount}")

# OrderService knows about Email, Inventory, AND Analytics.
# Adding a new downstream (e.g., loyalty points) requires modifying OrderService.
# If Analytics is down, the order fails.


# ════════════════════════════════════════════════════════════════
# WITH EDA — Event broker; loose coupling, independent consumers
# ════════════════════════════════════════════════════════════════

# ── Event definitions ──────────────────────────────────────────
@dataclass(frozen=True)
class Event:
    """Base envelope for all events."""
    event_id:   str
    event_type: str
    timestamp:  datetime
    source:     str

    @staticmethod
    def new_id() -> str:
        return str(uuid.uuid4())


@dataclass(frozen=True)
class OrderPlacedEvent(Event):
    order_id:    str
    customer_id: str
    amount:      Decimal
    currency:    str = "USD"

    @classmethod
    def create(cls, order_id: str, customer_id: str, amount: Decimal) -> "OrderPlacedEvent":
        return cls(
            event_id=cls.new_id(),
            event_type="order.placed",
            timestamp=datetime.now(tz=timezone.utc),
            source="order-service",
            order_id=order_id,
            customer_id=customer_id,
            amount=amount,
        )


@dataclass(frozen=True)
class PaymentProcessedEvent(Event):
    order_id:       str
    transaction_id: str
    amount:         Decimal
    success:        bool

    @classmethod
    def create(cls, order_id: str, transaction_id: str, amount: Decimal, success: bool) -> "PaymentProcessedEvent":
        return cls(
            event_id=cls.new_id(),
            event_type="payment.processed",
            timestamp=datetime.now(tz=timezone.utc),
            source="payment-service",
            order_id=order_id,
            transaction_id=transaction_id,
            amount=amount,
            success=success,
        )


# ── In-process event broker ────────────────────────────────────
EventHandler = Callable[[Event], None]


class EventBroker:
    """
    Simple in-process pub/sub broker.
    Production: replace with Kafka, RabbitMQ, or AWS EventBridge.
    The OrderService and consumers only know about EventBroker — never each other.
    """

    def __init__(self) -> None:
        self._handlers: dict[str, list[EventHandler]] = {}

    def subscribe(self, event_type: str, handler: EventHandler) -> None:
        if event_type not in self._handlers:
            self._handlers[event_type] = []
        self._handlers[event_type].append(handler)
        print(f"[Broker] '{handler.__qualname__}' subscribed to '{event_type}'")

    def publish(self, event: Event) -> None:
        print(f"\n[Broker] Publishing '{event.event_type}' (id={event.event_id[:8]}...)")
        handlers = self._handlers.get(event.event_type, [])
        if not handlers:
            print(f"[Broker] No subscribers for '{event.event_type}'")
            return
        for handler in handlers:
            try:
                handler(event)
            except Exception as e:
                # In production: move to Dead Letter Queue
                print(f"[Broker] Handler '{handler.__qualname__}' failed: {e}")


# ── Producer — knows only about the broker, never about consumers ──
class OrderService:
    """Places orders and publishes events. Has no knowledge of Email, Inventory, or Analytics."""

    def __init__(self, broker: EventBroker) -> None:
        self._broker = broker

    def place_order(self, customer_id: str, amount: Decimal) -> str:
        order_id = str(uuid.uuid4())

        # Core responsibility: persist the order
        print(f"[OrderService] Order {order_id[:8]}... persisted")

        # Publish the event — job done. No direct calls.
        event = OrderPlacedEvent.create(order_id, customer_id, amount)
        self._broker.publish(event)

        return order_id


# ── Consumers — each subscribes independently, no dependency on OrderService ──
class EmailService:
    """Reacts to order and payment events to send user emails."""

    def __init__(self, broker: EventBroker) -> None:
        broker.subscribe("order.placed",       self.on_order_placed)
        broker.subscribe("payment.processed",  self.on_payment_processed)

    def on_order_placed(self, event: OrderPlacedEvent) -> None:  # type: ignore[override]
        print(f"[EmailService] Sending order confirmation to customer {event.customer_id} "
              f"for order {event.order_id[:8]}... (${event.amount})")

    def on_payment_processed(self, event: PaymentProcessedEvent) -> None:  # type: ignore[override]
        status = "successful" if event.success else "failed"
        print(f"[EmailService] Payment {status} email → order {event.order_id[:8]}...")


class InventoryService:
    """Reacts to order.placed to reserve stock."""

    def __init__(self, broker: EventBroker) -> None:
        broker.subscribe("order.placed", self.on_order_placed)

    def on_order_placed(self, event: OrderPlacedEvent) -> None:  # type: ignore[override]
        print(f"[InventoryService] Reserving stock for order {event.order_id[:8]}...")


class AnalyticsService:
    """Tracks order and payment events for business intelligence."""

    def __init__(self, broker: EventBroker) -> None:
        broker.subscribe("order.placed",      self.on_order_placed)
        broker.subscribe("payment.processed", self.on_payment_processed)

    def on_order_placed(self, event: OrderPlacedEvent) -> None:  # type: ignore[override]
        print(f"[Analytics] Tracked order.placed: ${event.amount} from {event.customer_id}")

    def on_payment_processed(self, event: PaymentProcessedEvent) -> None:  # type: ignore[override]
        print(f"[Analytics] Tracked payment.processed: success={event.success}")


# ── NEW consumer added without touching OrderService ──────────
class LoyaltyService:
    """NEW: Reacts to order.placed to award loyalty points — zero changes to OrderService."""

    def __init__(self, broker: EventBroker) -> None:
        broker.subscribe("order.placed", self.on_order_placed)

    def on_order_placed(self, event: OrderPlacedEvent) -> None:  # type: ignore[override]
        points = int(event.amount)
        print(f"[LoyaltyService] Awarded {points} points to customer {event.customer_id}")


# ── Composition Root ───────────────────────────────────────────
if __name__ == "__main__":
    broker = EventBroker()

    # Wire consumers — they self-register by subscribing in __init__
    email_service    = EmailService(broker)
    inventory_service = InventoryService(broker)
    analytics_service = AnalyticsService(broker)
    loyalty_service  = LoyaltyService(broker)   # Added without touching OrderService

    # Producer
    order_service = OrderService(broker)

    print("\n=== Placing Order ===")
    order_id = order_service.place_order("CUST-001", Decimal("49.99"))

    print("\n=== Processing Payment ===")
    payment_event = PaymentProcessedEvent.create(order_id, "txn_abc123", Decimal("49.99"), True)
    broker.publish(payment_event)

Production-Ready Example

The most instructive production EDA challenge: an order fulfillment pipeline with durable event persistence, idempotent consumers, retry logic, and a dead letter queue. This shows EDA as it actually runs in production — not just as an in-process pub/sub.

🐍 Python (Production)

from __future__ import annotations
from dataclasses import dataclass, field
from datetime import datetime, timezone
from typing import Callable, Optional
from decimal import Decimal
from enum import Enum
import uuid
import json
import time


# ════════════════════════════════════════════════════════════════
# Production EDA concerns: idempotency, retry, DLQ, persistence
# ════════════════════════════════════════════════════════════════

class EventStatus(Enum):
    PENDING    = "pending"
    PROCESSING = "processing"
    COMPLETED  = "completed"
    FAILED     = "failed"
    DLQ        = "dlq"


@dataclass
class EventEnvelope:
    """Durable event record with delivery metadata."""
    event_id:     str
    event_type:   str
    source:       str
    timestamp:    datetime
    payload:      dict
    version:      str = "1.0"
    attempts:     int = 0
    max_attempts: int = 3
    status:       EventStatus = EventStatus.PENDING
    error:        Optional[str] = None

    def to_json(self) -> str:
        return json.dumps({
            "eventId":    self.event_id,
            "eventType":  self.event_type,
            "source":     self.source,
            "timestamp":  self.timestamp.isoformat(),
            "version":    self.version,
            "payload":    self.payload,
            "attempts":   self.attempts,
        })

    @classmethod
    def create(cls, event_type: str, source: str, payload: dict) -> "EventEnvelope":
        return cls(
            event_id=str(uuid.uuid4()),
            event_type=event_type,
            source=source,
            timestamp=datetime.now(tz=timezone.utc),
            payload=payload,
        )


# ── Idempotency store — prevents double-processing ─────────────
class IdempotencyStore:
    """Tracks which event+consumer combinations have been processed."""

    def __init__(self) -> None:
        self._processed: set[str] = set()

    def is_processed(self, event_id: str, consumer_id: str) -> bool:
        return f"{event_id}:{consumer_id}" in self._processed

    def mark_processed(self, event_id: str, consumer_id: str) -> None:
        self._processed.add(f"{event_id}:{consumer_id}")


# ── Dead Letter Queue ──────────────────────────────────────────
@dataclass
class DeadLetterEntry:
    envelope:    EventEnvelope
    consumer_id: str
    failed_at:   datetime
    last_error:  str


class DeadLetterQueue:
    def __init__(self) -> None:
        self._entries: list[DeadLetterEntry] = []

    def push(self, envelope: EventEnvelope, consumer_id: str, error: str) -> None:
        entry = DeadLetterEntry(
            envelope=envelope,
            consumer_id=consumer_id,
            failed_at=datetime.now(tz=timezone.utc),
            last_error=error,
        )
        self._entries.append(entry)
        print(f"[DLQ] ⚠️  Event {envelope.event_id[:8]}... → {consumer_id} moved to DLQ: {error}")

    @property
    def entries(self) -> list[DeadLetterEntry]: return self._entries


# ── Consumer registration ──────────────────────────────────────
@dataclass
class ConsumerRegistration:
    consumer_id: str
    event_type:  str
    handler:     Callable[[EventEnvelope], None]


# ── Production-grade event broker ─────────────────────────────
class ProductionEventBroker:
    """
    Event broker with:
    - At-least-once delivery
    - Idempotent consumer protection
    - Retry with exponential backoff
    - Dead Letter Queue for permanently failed events
    - Durable event log (in-memory for demo; use Kafka/Postgres in production)
    """

    def __init__(self, max_retries: int = 3) -> None:
        self._consumers:      list[ConsumerRegistration] = []
        self._event_log:      list[EventEnvelope]        = []
        self._idempotency:    IdempotencyStore            = IdempotencyStore()
        self._dlq:            DeadLetterQueue             = DeadLetterQueue()
        self._max_retries:    int                         = max_retries

    @property
    def dead_letter_queue(self) -> DeadLetterQueue:
        return self._dlq

    @property
    def event_log(self) -> list[EventEnvelope]:
        return self._event_log

    def subscribe(
        self,
        event_type:  str,
        handler:     Callable[[EventEnvelope], None],
        consumer_id: str,
    ) -> None:
        self._consumers.append(ConsumerRegistration(consumer_id, event_type, handler))
        print(f"[Broker] '{consumer_id}' subscribed to '{event_type}'")

    def publish(self, envelope: EventEnvelope) -> None:
        """Publish an event. Delivers to all registered consumers with retry and DLQ."""
        self._event_log.append(envelope)
        print(f"\n[Broker] Publishing '{envelope.event_type}' (id={envelope.event_id[:8]}...)")

        for reg in self._consumers:
            if reg.event_type != envelope.event_type:
                continue

            # Idempotency check — skip if already processed
            if self._idempotency.is_processed(envelope.event_id, reg.consumer_id):
                print(f"[Broker] ⏭️  Skipping {reg.consumer_id} — already processed (idempotent)")
                continue

            self._deliver_with_retry(envelope, reg)

    def _deliver_with_retry(self, envelope: EventEnvelope, reg: ConsumerRegistration) -> None:
        """Deliver with exponential backoff retry. Move to DLQ on exhaustion."""
        last_error: str = ""

        for attempt in range(1, self._max_retries + 1):
            try:
                envelope.attempts = attempt
                reg.handler(envelope)
                self._idempotency.mark_processed(envelope.event_id, reg.consumer_id)
                print(f"[Broker] ✓ {reg.consumer_id} processed event (attempt {attempt})")
                return
            except Exception as e:
                last_error = str(e)
                wait = 2 ** (attempt - 1)  # exponential backoff: 1s, 2s, 4s
                print(f"[Broker] ✗ {reg.consumer_id} failed attempt {attempt}/{self._max_retries}: {e}")
                if attempt < self._max_retries:
                    print(f"[Broker] Retrying in {wait}s...")
                    time.sleep(wait)

        # All retries exhausted — move to DLQ
        envelope.status = EventStatus.DLQ
        self._dlq.push(envelope, reg.consumer_id, last_error)


# ════════════════════════════════════════════════════════════════
# Application — OrderService + consumers
# ════════════════════════════════════════════════════════════════

class OrderProcessingService:
    """Places orders and emits OrderPlaced events."""

    def __init__(self, broker: ProductionEventBroker) -> None:
        self._broker = broker

    def place_order(self, customer_id: str, amount: Decimal, items: list[dict]) -> str:
        order_id = str(uuid.uuid4())

        # Persist order (simplified)
        print(f"[OrderService] Order {order_id[:8]}... saved")

        # Publish event — event-carried state transfer pattern
        envelope = EventEnvelope.create(
            event_type="order.placed",
            source="order-service",
            payload={
                "orderId":    order_id,
                "customerId": customer_id,
                "amount":     str(amount),
                "currency":   "USD",
                "items":      items,
                "placedAt":   datetime.now(tz=timezone.utc).isoformat(),
            }
        )
        self._broker.publish(envelope)
        return order_id


# ── Consumers with realistic behavior ─────────────────────────

_attempt_counts: dict[str, int] = {}

def email_consumer(envelope: EventEnvelope) -> None:
    """Sends order confirmation email. Idempotent: same email not sent twice."""
    payload = envelope.payload
    print(f"[EmailService] ✉  Confirmation → {payload['customerId']}: "
          f"Order {payload['orderId'][:8]}... ${payload['amount']}")


def inventory_consumer(envelope: EventEnvelope) -> None:
    """Reserves inventory. Simulates a transient failure on first attempt."""
    payload = envelope.payload
    order_id = payload["orderId"]

    # Simulate transient failure on first attempt
    count = _attempt_counts.get(order_id, 0) + 1
    _attempt_counts[order_id] = count

    if count == 1:
        raise RuntimeError("Inventory service temporarily unavailable (transient)")

    print(f"[InventoryService] 📦 Stock reserved for Order {order_id[:8]}...")


def analytics_consumer(envelope: EventEnvelope) -> None:
    """Tracks event for business intelligence. Always succeeds."""
    payload = envelope.payload
    print(f"[Analytics] 📊 Tracked order.placed: ${payload['amount']} from {payload['customerId']}")


def fraud_consumer(envelope: EventEnvelope) -> None:
    """Runs fraud scoring. Simulates a permanent failure."""
    raise RuntimeError("Fraud service is down — permanent failure")


# ── Composition Root ───────────────────────────────────────────
if __name__ == "__main__":
    broker = ProductionEventBroker(max_retries=3)

    # Register consumers with unique IDs (used for idempotency tracking)
    broker.subscribe("order.placed", email_consumer,     consumer_id="email-service-v1")
    broker.subscribe("order.placed", inventory_consumer, consumer_id="inventory-service-v1")
    broker.subscribe("order.placed", analytics_consumer, consumer_id="analytics-service-v1")
    broker.subscribe("order.placed", fraud_consumer,     consumer_id="fraud-service-v1")

    order_service = OrderProcessingService(broker)

    print("\n" + "=" * 60)
    print("=== PLACING ORDER ===")
    print("=" * 60)
    order_id = order_service.place_order(
        customer_id="CUST-001",
        amount=Decimal("129.99"),
        items=[{"sku": "SKU-001", "qty": 2, "price": "64.99"}]
    )

    print("\n" + "=" * 60)
    print("=== IDEMPOTENCY TEST — Publishing same event again ===")
    print("=" * 60)
    # Replay of the same event — idempotency prevents double-processing
    duplicate_envelope = EventEnvelope.create(
        event_type="order.placed",
        source="order-service",
        payload={"orderId": order_id, "customerId": "CUST-001", "amount": "129.99", "currency": "USD", "items": []}
    )
    # Override eventId to simulate replay of the original event
    original_event_id = broker.event_log[0].event_id
    duplicate_envelope.event_id = original_event_id
    broker.publish(duplicate_envelope)

    print("\n" + "=" * 60)
    print(f"=== DLQ CONTENTS ({len(broker.dead_letter_queue.entries)} entries) ===")
    print("=" * 60)
    for entry in broker.dead_letter_queue.entries:
        print(f"  Event: {entry.envelope.event_id[:8]}... | Consumer: {entry.consumer_id} | Error: {entry.last_error}")

    print("\n" + "=" * 60)
    print(f"=== EVENT LOG ({len(broker.event_log)} events) ===")
    print("=" * 60)
    for evt in broker.event_log:
        print(f"  {evt.event_id[:8]}... | {evt.event_type} | {evt.timestamp.strftime('%H:%M:%S')}")

Real-World Use Cases

EDA appears wherever direct coupling between services would cause fragility, poor scalability, or development bottlenecks.

E-commerce order fulfillment: Placing an order triggers email confirmation, inventory reservation, payment processing, fraud scoring, loyalty point calculation, and analytics tracking. With direct calls, adding any new downstream action requires modifying the order service. With EDA, each downstream service subscribes to order.placed and reacts independently. New consumers are added without touching the order service.

Financial transaction processing: A payment is recorded once as an event. The accounting system, the compliance system, the fraud detection system, the customer notification system, and the analytics system each consume the event independently. The payment service never calls any of them directly.

IoT and sensor processing: Sensor readings are published as events to a stream. Alerting consumers watch for threshold breaches; aggregation consumers compute rolling averages; storage consumers persist raw readings; ML consumers update models. All react to the same stream independently and at different rates.

User journey tracking: A user registration publishes user.registered. The onboarding email, the CRM record creation, the welcome push notification, and the A/B test assignment all subscribe independently. Adding a new user acquisition campaign's tracking is adding a new subscriber — zero changes to the registration service.

Microservice integration: Services that would otherwise require direct API coupling can integrate through events. The inventory service publishes stock.low; the purchasing service subscribes and creates purchase orders. Neither service knows about the other's implementation, team, or deployment schedule.

Real-time dashboards: Events published by backend services are consumed by a stream processing layer (Kafka Streams, Apache Flink) that maintains aggregated state. Dashboards query the aggregated state rather than querying individual services — providing real-time metrics without polling.

Event sourcing and audit logs: Every state change is recorded as an event. The event log is the system's authoritative state. Current state is derived by replaying events. This provides a complete audit trail, the ability to reconstruct state at any historical point, and the ability to replay events to populate new projections.

Saga / distributed transaction management: Multi-service workflows that require coordination without distributed locks. A checkout saga publishes events and reacts to them to coordinate payment, inventory reservation, and shipping — with compensating events to roll back steps when a later step fails.

Language-Specific Mistakes and Anti-Patterns

# BAD: Blocking I/O inside an async event handler blocks the entire event loop
import asyncio

async def on_order_placed(event):
    # time.sleep blocks the entire event loop — no other handlers can run
    import time
    time.sleep(2)  # ← BLOCKS the event loop
    send_email(event.customer_id)   # this is also blocking

# GOOD: Use async I/O throughout; never block the event loop
async def on_order_placed(event):
    await asyncio.sleep(0)      # yield control; non-blocking
    await send_email_async(event.customer_id)   # awaitable, non-blocking

# BAD: Consumers mutate the event — other consumers see modified data
@dataclass
class OrderPlacedEvent:
    order_id: str
    amount: float
    # No frozen=True — mutable!

def inventory_handler(event: OrderPlacedEvent) -> None:
    event.amount = 0.0   # ← mutates the event! Analytics handler now sees $0

# GOOD: Frozen dataclasses or NamedTuples — events are immutable
@dataclass(frozen=True)
class OrderPlacedEvent:
    order_id: str
    amount: float
# Now: event.amount = 0.0 raises FrozenInstanceError immediately

Frequently Asked Questions

Q1: When should I use EDA instead of REST API calls?

Use EDA when the producer should not wait for downstream processing, when multiple consumers need to react to the same occurrence, or when the downstream consumer might be temporarily unavailable. Use REST when you need an immediate response (querying data, validating input, charging a payment where you need the result to continue), or when there is exactly one consumer and the operation is naturally synchronous.

A practical rule: if the caller would say "I need to know if this worked before I continue," use REST. If the caller would say "something happened — anyone who cares can deal with it," use EDA.

Q2: How do I handle events that need a response?

EDA is fundamentally one-way: the producer publishes and does not wait. When a response is genuinely needed, there are two approaches.

The first is Request-Reply over events: the producer publishes a request event with a correlationId and subscribes to a response topic. The consumer processes the request, publishes a response event with the same correlationId. The producer correlates the response to the original request. This is more complex than direct REST but preserves decoupling.

The second is a hybrid model: use REST for synchronous operations that need immediate responses (payment charging, data validation) and EDA for the downstream propagation of the results (payment confirmed → update inventory, send email, update analytics).

Q3: How do I maintain data consistency across services with EDA?

EDA does not provide atomic, distributed transactions across services. Instead, it enables eventual consistency: after all events have been processed, all services will agree on the state — but there is a window where they may temporarily disagree.

For workflows requiring multi-service coordination, the Saga Pattern orchestrates a sequence of events and compensating events. If a later step fails, compensating events roll back the earlier steps. The Saga can be choreography-based (services react to each other's events in sequence) or orchestration-based (a central saga orchestrator publishes commands and reacts to results).

The acceptance of eventual consistency is a design choice, not a compromise — it enables independent scaling and resilience that strict consistency would prevent.

Q4: How do I handle event schema evolution without breaking consumers?

Event schema evolution is one of the hardest practical challenges in EDA. The most reliable strategies are:

Backward-compatible additive changes: Add new optional fields to events. Consumers that don't know about the new field ignore it. Consumers that need it read it. Never remove or rename fields without a migration period.

Versioned event types: Publish order.placed.v1 and order.placed.v2 as separate event types. Consumers subscribe to the version they understand. A migration consumer can translate v1 events to v2 events.

Schema Registry: Tools like Confluent Schema Registry enforce schema compatibility rules at publish time — producers cannot publish schemas that would break registered consumers.

Event Envelope Versioning: Include a version field in the event envelope. Consumers check the version and handle each version explicitly, with a default fallback.

Q5: What is the difference between a message queue and an event bus?

A message queue delivers each message to exactly one consumer (the competing consumers pattern). Multiple consumer instances share the queue; each message is processed once, by one instance. Queue semantics are for task distribution — ensuring each unit of work is processed exactly once by exactly one worker.

An event bus (pub/sub) delivers each event to all subscribers. Each subscriber group receives every event independently. Bus semantics are for fan-out — ensuring every interested party reacts to every occurrence.

Production EDA systems typically use both: a pub/sub event bus for initial fan-out (each consumer group receives each event), and a message queue per consumer group for reliable processing within that group (multiple instances of the consumer share a queue, each processing different events from their group's queue).

Q6: How do I test event-driven systems?

Unit testing: Test handlers in isolation with direct calls. Pass a constructed EventEnvelope directly to the handler function — no broker required. The handler is a function; test it like one.

Integration testing: Test the full event flow with an in-process broker. Wire the producer and consumers to an in-process broker in the test. Publish an event; assert the consumer's side effects (messages sent, database state updated, etc.).

Contract testing: For distributed systems, use consumer-driven contract tests (Pact). Each consumer specifies the event shape it requires; the producer verifies that its published events satisfy all consumer contracts. This prevents schema changes from silently breaking consumers.

End-to-end testing: Use a test environment with a real broker (Kafka in Docker, RabbitMQ in Docker) for end-to-end tests that verify the full pipeline including delivery guarantees, retry behavior, and DLQ routing.

Q7: How do I debug event-driven systems when something goes wrong?

Debugging EDA systems requires different tooling than synchronous systems, because the cause of a problem may have occurred long before the symptom appears.

Correlation IDs: Every event should carry a correlationId that connects related events in a workflow. A user action generates a correlation ID; every event in the resulting workflow carries it. Filtering logs by correlation ID reveals the complete causal chain.

Event log querying: Treat the event log as a queryable database. When something is wrong, query the events: which events were published? Which were consumed? Which failed and how many times? Dead letter queues are goldmines — every entry is a documented failure with error message and context.

Distributed tracing: Tools like Jaeger, Zipkin, and OpenTelemetry propagate trace context through events. Each event carries span context; the consumer creates a child span. The result is a visual trace of the complete causal chain across services.

Event replay: When a consumer has a bug that produced incorrect side effects, fix the bug and replay the events it should have processed. Event sourcing systems support this natively; systems with durable event logs (Kafka with long retention) can replay to a specific consumer group.

Q8: What are the operational challenges of running EDA in production?

EDA shifts complexity from synchronous code to asynchronous infrastructure. The operational challenges are real:

Consumer lag monitoring: Consumers may fall behind producers under load. Monitor consumer lag (the difference between the latest published event and the latest consumed event) and alert on lag growth.

Dead Letter Queue management: DLQs accumulate events that failed to process. Monitor DLQ size, alert on growth, and have runbooks for investigating and reprocessing DLQ entries.

Exactly-once vs. at-least-once: Most production brokers offer at-least-once delivery. Ensure all consumers are idempotent — the same event processed twice must produce the same result as processing it once.

Event ordering: Many brokers guarantee ordering within a partition but not across partitions. If consumers require ordered processing, ensure events that must be ordered share a partition key.

Schema governance: Without coordination, producers evolve schemas in ways that break consumers. A schema registry with compatibility enforcement prevents this at publish time.

Broker availability: The broker is a critical dependency. Design consumers to handle broker unavailability gracefully — retry connections, use local buffers, and have runbooks for broker outages.

Q9: Should every system use EDA?

No. EDA is the right tool for specific problems; it is not a default architecture. Systems that are CRUD-heavy with immediate consistency requirements are better served by synchronous request-response. Small applications with few services gain no benefit from an event broker's operational complexity.

EDA earns its complexity when: you have multiple services that react to the same occurrence, you need independent scalability between producers and consumers, you need resilience to consumer failures, or you need a durable event log for audit or replay purposes.

A monolith with an in-process event bus (as shown in the beginner examples) captures many of EDA's benefits without distributed infrastructure complexity. Start simple; evolve to a distributed broker when the scale and team boundaries genuinely require it.

Q10: How do I prevent event storms (cascading event loops)?

An event storm occurs when a consumer publishes events in response to consumed events, and those events trigger more events, creating an unbounded cascade. Prevention strategies:

Limit event chains: Design event-driven workflows to have a bounded depth. A PaymentProcessed event triggers ConfirmationEmail — which does not publish any further events. Define the chain explicitly and resist the urge to have every step publish its own events.

Use commands for orchestration: When a step must trigger a next step, publish a command (an instruction) rather than an event (a fact). Commands are targeted and processed once; events are broadcast and may trigger multiple consumers.

Circuit breakers: A consumer that has processed N events in the last M seconds may be in a storm. A circuit breaker that temporarily stops processing breaks the cascade.

Idempotency: Even if an event is published multiple times due to a storm, idempotent consumers ensure the side effects are applied only once — limiting the blast radius of accidental loops.

Key Takeaways

🎯 Core Concept: Event-Driven Architecture is a software design paradigm where components communicate by producing and consuming immutable events rather than calling each other directly. A producer detects or causes something to happen and publishes an event describing the occurrence. Consumers subscribe independently and react on their own schedule. The event broker delivers events from producers to consumers, ensuring that neither party needs to know about the other. The result is temporal decoupling — producer and consumer operate independently in time — and spatial decoupling — they are not bound to each other's availability, location, or implementation.

🔑 Key Benefits:

• Loose coupling: Producers have no knowledge of consumers — adding or removing a consumer requires no change to the producer
• Independent scalability: Each consumer scales on its own — if email processing lags, scale the email consumer without touching the order service
• Resilience: Consumer failures do not propagate to producers; the broker retains events until the consumer recovers
• Extensibility: New behavior is added by adding new consumers — the open/closed principle at the architecture level
• Natural audit trail: The event log is a complete record of everything that happened, in order, with timestamps
• Polyglot integration: Services share an event schema, not a language or framework — each service is independently implemented

🌐 Language-Specific Highlights:

• Python: Use asyncio throughout event handlers — never block with time.sleep() or synchronous I/O in an async context; @dataclass(frozen=True) enforces event immutability at the language level; asyncio.Queue for in-process async event passing; Celery or Dramatiq for task-queue-style consumer scaling
• TypeScript: Use discriminated union types for typed event handling — switch (event.eventType) with exhaustiveness checking; Promise.allSettled() instead of Promise.all() in broker delivery (one handler failure shouldn't prevent others); EventEmitter for simple in-process; bullmq or kafkajs for production brokers
• Java: Use record types for immutable events; CompletableFuture and ExecutorService for async handler execution; Spring's ApplicationEventPublisher for in-process events; Spring Kafka or Spring AMQP for distributed brokers; @EventListener for declarative subscription
• JavaScript: Node.js EventEmitter is the idiomatic in-process broker; store EventEmitter references (not as global singletons) for testability; Bull or BullMQ for durable Redis-backed queues; avoid emitter.on() without a corresponding emitter.off() for cleanup
• C#: MediatR for in-process event mediation; System.Threading.Channels for high-throughput in-process async queues; MassTransit for distributed broker abstraction (supports RabbitMQ, Azure Service Bus, Amazon SQS); IHostedService for background consumer workers
• PHP: Laravel's Event facade and ShouldQueue interface for async event handling via Laravel Queues; Symfony EventDispatcher for in-process; php-amqplib for RabbitMQ; always dispatch events after database transaction commits — never inside the transaction
• Go: Channels are the idiomatic Go event queue; sync.WaitGroup for waiting on all handlers; select for fan-out to multiple channels; define interfaces at the point of use (consumer package); sarama or confluent-kafka-go for Kafka; avoid shared mutable state in goroutine handlers — use channels to communicate
• Rust: tokio::sync::broadcast for async multi-consumer event channels; Arc<Mutex<T>> for shared handler state (never Rc<RefCell<T>> in multi-threaded handlers); rdkafka for Kafka; match exhaustiveness on sealed event enums catches missing handler cases at compile time
• Dart: StreamController.broadcast() for in-process pub/sub; store StreamSubscription references and cancel in dispose() to prevent memory leaks; rxdart for reactive stream operators (debounce, throttle, flatMap); BLoC pattern uses streams as an application-level event bus
• Swift: Combine's PassthroughSubject is the idiomatic in-process event bus; always use [weak self] capture in sink closures to prevent retain cycles; store AnyCancellable in a Set<AnyCancellable> tied to the object's lifecycle; NotificationCenter for system-level events
• Kotlin: SharedFlow for hot multi-subscriber streams; StateFlow for events that also carry current state; filterIsInstance<T>() for type-safe event filtering; always collect flows in a lifecycle-aware scope (viewLifecycleOwner.lifecycleScope in Android, coroutineScope in server); use Dispatchers.IO for blocking I/O in handlers

📋 Core EDA Patterns:

• Simple Event Notification: Event contains only an ID; consumers query for details — lightweight events, more network calls
• Event-Carried State Transfer: Event contains all needed data — consumers are truly autonomous, no follow-up queries needed
• Event Sourcing: State is derived from replaying the event log — complete audit trail, time-travel debugging, projection rebuilding
• CQRS: Commands produce events; events update read models — independent optimization of read and write paths
• Saga Pattern: Multi-step workflows coordinated through events and compensating events — distributed consistency without distributed locks

⚠️ EDA Anti-Patterns to Avoid:

• Publishing events inside database transactions — if the transaction rolls back, the event is already in-flight
• Mutable events — consumers share the same object reference in in-process brokers; mutation corrupts other handlers' data
• Events as commands (imperative naming: SendEmail instead of OrderPlaced) — events describe facts, not instructions
• Fat events with internal implementation details — consumers couple to producer internals and break when internal schemas change
• No idempotency — at-least-once delivery means handlers must handle duplicate events gracefully
• No Dead Letter Queue — failed events silently disappear without DLQ, causing lost data with no visibility
• Global event emitter singletons — prevents injection, breaks tests, creates invisible global coupling
• Collecting flows in GlobalScope (Kotlin) or not cancelling subscriptions (Dart/Swift) — memory leaks and zombie listeners

🛠️ Best Practices Across Languages:

1. Events are facts, not commands: Use past tense naming (OrderPlaced, PaymentProcessed, UserRegistered); let consumers decide what to do
2. Events are immutable: Use frozen/readonly data structures; never modify an event after publishing
3. Design for at-least-once delivery: Every consumer must be idempotent — track processed event IDs, use database constraints, or natural idempotency
4. Include a Dead Letter Queue: Every consumer should have a DLQ for events that fail after all retries — with monitoring and runbooks
5. Carry correlation IDs: Thread a correlationId through all events in a workflow — essential for debugging distributed traces
6. Version your event schemas: Include a version field; use a schema registry for large teams; never remove fields without a migration period
7. Dispatch events after transactions commit: Collect events during a transaction; dispatch after successful commit — prevents phantom events from rolled-back transactions

💡 Delivery Guarantee Summary:

• At-most-once: Fire and forget — events may be lost; acceptable for metrics and non-critical notifications
• At-least-once: Never lose events; events may be delivered multiple times — requires idempotent consumers; the standard production choice
• Exactly-once: Every event processed precisely once — hardest to achieve; requires transactional coordination between broker and consumer state store

🎁 Advanced Techniques:

• Event Sourcing + CQRS: Store state as an append-only event log; derive read models (projections) by replaying events — enables time-travel debugging, complete audit trails, and rebuilding any read model from scratch
• Consumer-Driven Contract Testing (Pact): Each consumer defines the event schema it requires; the producer CI verifies its events satisfy all consumer contracts — prevents schema evolution from silently breaking consumers
• Outbox Pattern: Write events to an outbox table in the same database transaction as the state change; a separate relay process reads the outbox and publishes to the broker — guarantees that events are always published if the transaction commits
• Saga Choreography vs. Orchestration: Choreography has each service publish and react to events in sequence (no central coordinator — more decoupled, harder to visualize); orchestration has a dedicated saga manager publish commands and await results (centralized logic, easier to understand and monitor)
• Event Stream Processing: Connect events to a stream processor (Kafka Streams, Apache Flink, Spark Streaming) for windowed aggregations, pattern detection, and real-time analytics — turning the event log into a queryable, time-windowed computation engine

Event-Driven Architecture is the architectural answer to the question: "how do services communicate when they should not depend on each other?" The answer — they don't communicate directly at all. They describe what happened; others react. This inversion produces systems that are resilient because they tolerate failures silently, scalable because each part grows independently, and extensible because new behavior is always a new subscription, never a modification to existing code.

Want to dive deeper into architecture patterns and principles? Check out our comprehensive guides on:

• Dependency Injection
• SOLID Principles
• Observer Pattern
• CQRS Pattern
• Strategy Pattern Each guide includes examples in all 11 programming languages with language-specific best practices.