Event-Driven Architecture

The foundational principle of EDA where producers and consumers are temporally decoupled. A service that publishes an event does not wait for a response from the consumer. This is achieved through a message broker or event router (like Apache Kafka or RabbitMQ) that buffers events. This non-blocking I/O pattern prevents cascading failures, as a slow consumer does not block the producer. The result is a system that handles backpressure naturally and remains responsive under variable load.

A persistence model where the state of an entity is determined by a sequence of immutable events, rather than storing just the current state. The event store acts as the single source of truth. Key implications include:

• Full Audit Trail: Every state change is recorded and replayable.
• Temporal Queries: The system's state can be reconstructed for any point in time.
• CQRS Alignment: Naturally pairs with Command Query Responsibility Segregation, separating write models (events) from read models (materialized views).

Services in an EDA are location-independent and technology-agnostic. A producer emits an event to a logical channel without knowing the identity, quantity, or implementation of consumers. This allows teams to independently deploy, scale, and update services. A consumer written in Go can process events from a producer written in Python, as long as both adhere to the shared event schema. This drastically reduces coordination overhead and enables polyglot persistence.

A decentralized workflow pattern where services react to events autonomously, without a central orchestrator. Each service listens for specific events and publishes new ones, forming a reactive chain. For example, an OrderPlaced event triggers the InventoryService to reserve stock, which then emits an InventoryReserved event for the PaymentService. This contrasts with orchestration, where a central conductor commands each step. Choreography reduces single points of failure but requires robust monitoring.

EDA enables continuous, unbounded data processing via stream processing platforms. Instead of batch ETL jobs, systems like Apache Flink or Kafka Streams process events as they arrive, enabling sub-second latency for analytics and actions. This pattern is critical for:

• Fraud Detection: Analyzing transaction patterns in real-time.
• Dynamic Pricing: Adjusting offers based on live demand signals.
• Operational Dashboards: Providing live views of business metrics.

The contract between producers and consumers is the event schema. To maintain compatibility as systems evolve, EDA relies on a Schema Registry. This enforces compatibility types:

• Backward Compatibility: Consumers can read events produced with a newer schema.
• Forward Compatibility: Consumers can read events produced with an older schema.
• Full Compatibility: Both conditions are met. Formats like Apache Avro and Protobuf are standard, ensuring that a field rename or addition does not break downstream services.

A persistence pattern where state changes are stored as an immutable sequence of events rather than as a current state snapshot. The current state is derived by replaying the event log.

• Event Store: The append-only ledger of all domain events
• Projection: A read model built by folding events into a query-optimized view
• CQRS: Command Query Responsibility Segregation, often paired with event sourcing

This pattern provides a complete audit trail and enables temporal queries to reconstruct system state at any point in time.

While often conflated, these patterns differ in intent and coupling:

• Event-Driven: Producers broadcast facts that have already occurred (e.g., OrderPlaced). Producers do not expect or know about downstream consumers.
• Message-Driven: Producers send commands or requests to a specific destination (e.g., ProcessPayment). There is implicit expectation of a receiver.

Events are past-tense notifications; messages are imperative instructions. This distinction affects system coupling and evolution.

Mechanisms that prevent a fast producer from overwhelming a slow consumer in asynchronous systems. Without backpressure, consumers experience buffer bloat and eventual out-of-memory crashes.

• Reactive Streams: A standard for asynchronous stream processing with non-blocking backpressure
• Consumer Prefetch Limits: Configuring how many unacknowledged messages a consumer can hold
• Load Shedding: Intentionally dropping low-priority events when queues exceed thresholds

Proper flow control ensures system stability under variable load conditions.

The formal contract defining the structure, types, and compatibility rules of events. Schema evolution is critical because producers and consumers deploy independently.

• Schema Registry: A centralized service (e.g., Confluent Schema Registry) that stores and validates schemas
• Compatibility Types: BACKWARD, FORWARD, and FULL compatibility modes govern safe evolution
• Apache Avro & Protobuf: Compact binary serialization formats with built-in schema support

Breaking schema changes without versioning cause poison pill messages that crash consumers.

A specialized queue that stores events that cannot be processed successfully after exhausting retry policies. DLQs prevent poison messages from blocking entire processing pipelines.

• Redrive Policy: Configures how many times a message is retried before moving to the DLQ
• Replay Capability: Operators can inspect, fix, and republish DLQ messages after root cause resolution
• Observability Integration: DLQ depth is a critical alerting metric for system health

Without a DLQ strategy, a single malformed event can halt all downstream processing.