What is Event-Driven Architecture?

Event-driven architecture (EDA) is a style where services communicate by emitting events that describe something that has already happened, and by reacting to events they care about. Producers do not know who consumes their events; consumers do not know who produced them.

An event is an immutable record of a fact: 'Order 42 was created at 10:00:00.123'. It is past tense; the work has already been done. This is the key difference from a command (a request to do something) or a query (a request to learn something).

---------- EDA at a glance ----------
  [OrderService] --emits--> 'OrderCreated' --> [EVENT BUS]
                                                  |
                +---------------------------------+--------------------+
                v                v                v                    v
        [InventoryService]  [BillingService]  [Notification]    [Analytics]

No service calls another. The event bus delivers the event to every interested subscriber.

EDA vs Request/Response

In request/response, the producer knows the consumer and waits for a reply.

---------- Request/response ----------
  ServiceA --(call)--> ServiceB
            <--(reply)--

In EDA, the producer emits and forgets.

---------- Event-driven ----------
  ServiceA --(emit OrderCreated)--> [BUS] --> ServiceB
                                          --> ServiceC
                                          --> ServiceD

Most real systems mix both. User-facing APIs are request/response; back-end orchestration and integration are event-driven.

Three Patterns Inside EDA

EDA is a family. Picking the right variant matters.

1. Event Notification (the simplest)

The event carries only an identifier and minimal context. Consumers fetch full data from the producer if they need more.

// Event Notification: small, fetch-on-demand
{
    "type": "OrderCreated",
    "orderId": "o-42",
    "timestamp": "2026-04-26T10:00:00.123Z"
}

Pros: small events, no schema duplication. Cons: every consumer hits the producer's API to get details, recreating coupling.

2. Event-Carried State Transfer

The event carries all the state a consumer would need.

// Event-Carried State Transfer: full payload
{
    "type": "OrderCreated",
    "orderId": "o-42",
    "customerId": "c-7",
    "items": [
        { "sku": "abc", "qty": 2, "price": 19.99 },
        { "sku": "xyz", "qty": 1, "price": 49.99 }
    ],
    "totalAmount": 89.97,
    "currency": "USD",
    "timestamp": "2026-04-26T10:00:00.123Z"
}

Pros: consumers can build their own materialized view without calling the producer; true loose coupling. Cons: larger events, schema versioning becomes critical, data duplicated across consumers.

This is the pattern most modern EDA systems use.

3. Event Sourcing

The entire state of the system is derived from a log of events. To know the current balance of an account, replay every Credit/Debit event for that account. The event log is the source of truth; the application state is a derived view.

This is a more advanced pattern (covered in detail in the Advanced track lesson 'Event Sourcing & CQRS') and not the same thing as EDA. Use event sourcing when you need a perfect audit trail or time-travel queries; otherwise, plain event-carried state transfer is simpler.

The Event Bus

The event bus is the infrastructure that routes events from producers to subscribers. The choice of bus shapes the system's properties.

For most modern systems, Kafka (or its managed equivalent) is the default for high-throughput EDA, and EventBridge or SNS is the default for AWS-native lower-volume integration.

A Concrete Example: E-Commerce Checkout

Request/response version:

---------- Request/response checkout ----------
  Client --POST /checkout--> [Order Service]
                                  |
                                  |--call--> [Inventory] reserve
                                  |--call--> [Payment] charge
                                  |--call--> [Shipping] create label
                                  |--call--> [Email] send confirmation
                                  v
                                returns 200 only after all succeed

Problems: payment service down -> entire checkout fails. Email service slow -> checkout slow. Adding a loyalty service requires changing the order service.

Event-driven version:

---------- Event-driven checkout ----------
  Client --POST /checkout--> [Order Service]
                                  |
                                  |--write order to DB--
                                  |--emit 'OrderCreated' to Kafka--
                                  v
                              returns 202 (Accepted)

  [Kafka topic: orders.created]
          |
          +--> [Inventory] reserves stock; emits 'InventoryReserved'
          +--> [Payment] charges card; emits 'PaymentCompleted'
          +--> [Email] sends confirmation
          +--> [Loyalty] awards points (added later, no order-service change)
          +--> [Analytics] increments funnel metric

Properties:

• Order service responds in ~10 ms (just write + emit). Customer sees 'Processing' immediately.
• Each downstream service runs at its own pace and can fail independently.
• New consumers (loyalty, fraud check, recommendation) plug into the existing event without any change to the order service.
• The trade-off: the customer might see 'Processing' for a few seconds before all side effects complete.

Schema Design and Versioning

The second-most-important rule of EDA after 'events are immutable past-tense facts': events are a contract. Once a producer emits an event with a schema, every consumer depends on that schema. Breaking changes break consumers silently.

Versioning strategies

1. Additive changes are safe (add new optional fields). Old consumers ignore unknown fields.

2. Breaking changes require a new event type or a version field. Common patterns:

• New event name: OrderCreated.v2. Both versions emitted in parallel during migration.
• Version field: { "type": "OrderCreated", "schemaVersion": 2, ... }. Consumers handle both.

3. Schema registry: Confluent Schema Registry, AWS Glue Schema Registry, or EventBridge Schema Registry stores all event schemas centrally and enforces compatibility rules (forward-compatible, backward-compatible, full).

// AVRO schema in registry, compatibility = BACKWARD
{
    "type": "record",
    "name": "OrderCreated",
    "fields": [
        { "name": "orderId", "type": "string" },
        { "name": "customerId", "type": "string" },
        { "name": "totalAmount", "type": "double" },
        { "name": "currency", "type": "string", "default": "USD" } // optional, default for old producers
    ]
}

Naming conventions

Use past tense and namespace by domain: orders.OrderCreated, orders.OrderShipped, users.EmailUpdated. This makes the topic taxonomy self-explanatory.

Pseudocode: Producer and Consumer

// Producer
async function createOrder(req) {
    const order = await db.orders.insert(req.body);

    await kafka.publish('orders.OrderCreated', {
        type: 'OrderCreated',
        schemaVersion: 1,
        orderId: order.id,
        customerId: order.customerId,
        totalAmount: order.totalAmount,
        currency: order.currency,
        timestamp: new Date().toISOString(),
        idempotencyKey: req.headers['x-idempotency-key'],
    });

    return { status: 'accepted', orderId: order.id };
}

// Consumer
async function onOrderCreated(event) {
    if (await db.processedEvents.find({ id: event.idempotencyKey })) return;

    await db.transaction(async (tx) => {
        await tx.processedEvents.insert({ id: event.idempotencyKey });
        await tx.inventory.reserve({ orderId: event.orderId, items: event.items });
    });

    await kafka.publish('orders.InventoryReserved', { orderId: event.orderId });
}

Operational Pitfalls

1. Event ordering

Kafka gives per-partition ordering only. If your consumer logic depends on processing events in causal order (e.g., 'OrderCreated' before 'OrderUpdated'), partition by the entity key (e.g., orderId) so all events for that entity land on one partition.

2. Idempotency is non-negotiable

Consumers will see duplicate events: producer retries, broker redelivery, consumer rebalances. Every consumer must include an idempotency check (dedupe table indexed by event ID).

3. Schema drift kills consumers

A producer team adds a required field; downstream consumers parsing strictly fail to deserialize. Use schema registries with compatibility enforcement to prevent this from making it past CI.

4. Observability is harder

A single user action (place order) now spans 5+ services and dozens of event handlers. Without correlation IDs and distributed tracing (OpenTelemetry, Jaeger, Datadog APM), debugging a failed checkout is impossible.

5. The event firehose problem

Kafka makes it easy to publish events. Teams over-publish - every state change becomes an event - and consumers drown. Be deliberate about event granularity; not every internal state change deserves a topic.

6. Eventual consistency in the UI

Users expect immediate feedback. After a 'create order' event, the order list page may not yet show the new order. Either fetch from the producer (defeats the purpose) or design the UI for eventual consistency (optimistic update + reconcile).

When NOT to Use EDA

EDA is a hammer; not every problem is a nail.

• Synchronous user-facing queries (load page, fetch profile). Use request/response with caching.
• Strong consistency requirements (transfer money, take a lock). Use direct calls or 2PC.
• Tight latency budgets within a single workflow (sub-50ms end-to-end). EDA's queue hops add latency.
• Small teams, single team, simple system. The decoupling benefit is small; the operational cost is real.

A good rule: use EDA for integration between bounded contexts, request/response within a bounded context.

Decision Matrix

How to Talk About This in an Interview

1. Start with coupling. 'I would use event-driven architecture so that adding new consumers does not require changing the producer.'
2. Pick the variant. 'Event-carried state transfer means each consumer can build its own view without calling back to the producer, which is what I want for true decoupling.'
3. Name the bus and justify. 'Kafka for high-throughput streams, EventBridge for AWS-native cross-service integration with rule-based routing.'
4. Always mention idempotency and ordering. 'Consumers will see duplicate events, so I will dedupe by event ID. Per-key ordering will be preserved by partitioning Kafka topics by entity ID.'
5. Bring up schema versioning. 'A schema registry with backward-compatibility enforcement prevents producer changes from breaking consumers silently.'
6. Acknowledge the trade-offs. 'EDA shifts complexity from synchronous coordination to async observability. We need correlation IDs and distributed tracing to debug end-to-end flows.'

Quick Review

• Events are immutable, past-tense facts. Producers emit; consumers react.
• Three flavors: event notification (lookup needed), event-carried state transfer (default), event sourcing (advanced).
• Pub/sub bus decouples producers from consumers. Adding a consumer is a deploy, not a producer change.
• Pick Kafka for throughput, EventBridge for AWS-native rule routing, SNS for simple fan-out.
• Idempotency, ordering, and schema versioning are mandatory.
• Use EDA between bounded contexts; use direct calls within them.
• Observability (correlation IDs, distributed tracing) is what makes EDA debuggable at scale.