Event-Driven Architecture Pattern: Brokers, Schemas, and Idempotent Consumers (2026)

Q: What is event-driven architecture in microservices?

Event-driven architecture replaces synchronous call graphs between services with an explicit event log. Producers publish events when state changes (OrderPlaced, PaymentCaptured, UserSignedUp) in past tense; consumers subscribe to events they care about and react in their own time, with their own retry semantics, at their own throughput. The producer never knows or names its consumers; consumers never call back into the producer. The coupling shifts from runtime call-flow to a stable contract — the event schema — managed in a registry. Operational properties: independent deployment of producers and consumers, natural back-pressure absorption (events accumulate in the broker), replayability (consumers can re-read history), and audit-grade history of every meaningful change.

Q: Kafka vs SNS+SQS vs NATS vs EventBridge — which broker should I choose?

Kafka is the high-throughput, replay-capable, ordered-by-partition default — choose for ordered streams, high throughput, replay, or a single backbone across many services; cost is operational complexity. SNS+SQS is the AWS-native fan-out pattern for cases where each consumer has its own queue and there is no requirement for global ordering or replay; near-zero operational burden. NATS JetStream is the low-latency, lightweight log alternative — sub-millisecond latency, small operational footprint, smaller ecosystem. AWS EventBridge is the integration bus for coarse business events flowing across services or accounts and SaaS integrations; moderate throughput, higher per-event cost, serverless-native. Pulsar is the geo-distributed, multi-tenant choice. Mature systems often run two or three brokers in parallel — Kafka for high-throughput data plane, SNS+SQS or EventBridge for business events, NATS for low-latency control planes — each in its sweet spot.

Q: Why are events named in past tense (OrderPlaced not RunInventoryUpdate)?

Past-tense naming forces producer-consumer decoupling. An event named "OrderPlaced" is a fact — something happened in the producer's domain. A "command" event named "RunInventoryUpdate" or "SendNotificationToUser" is a directive aimed at a specific consumer; the producer has named its consumer in the event itself, defeating the entire point of the pattern. Past-tense facts let any number of consumers subscribe and decide what to do with the fact (inventory decrements stock, notification sends an email, analytics updates a dashboard, a new recommendation consumer added next year reads the same fact without producer changes). Command-style events lock the producer into knowing about its downstream consumers, reintroducing the synchronous coupling the architecture was meant to escape.

Q: Why is a schema registry essential for event-driven architecture?

Without a schema registry, event-driven systems degrade silently. Producer adds a field that some consumers don't handle; producer renames a field and consumers parsing the old name silently get null; producer changes a field type and some consumers cast successfully and some throw. The failure modes are silent, data-quality-affecting, and persist for months before being noticed. A schema registry (Confluent, AWS Glue, Apicurio) enforces compatibility at publish time — incompatible schema changes are rejected, not silently corrupted into production. Schemas are versioned and reviewable in pull requests; consumers fetch the schema they were compiled against and the latest schema and decode events correctly across versions. Backward compatibility is the standard default (new consumers can read old data); full compatibility is required for high-fanout events.

Q: What does at-least-once delivery mean and why must consumers be idempotent?

Most brokers (Kafka, SQS, NATS JetStream, EventBridge, Pulsar) default to at-least-once delivery — any individual event may be delivered twice or more under normal failure conditions: a consumer crash after processing but before acking, a broker rebalance that reassigns a partition mid-batch, a network partition that retries a publish, a producer-side retry on ack timeout. The consumer must be designed assuming "processing the same event twice has the same effect as processing it once." The standard mechanism is a deduplication store (Redis, DynamoDB, a database table) keyed by a stable event ID; before processing, the consumer checks the store, marks the event as processing, executes the business logic, marks done, and acks. Store retention should exceed the maximum redelivery window (broker retention plus consumer-lag tolerance). For full coverage see the dedicated Idempotency in Distributed Systems article in this series.

Q: Is exactly-once delivery possible in event-driven systems?

In narrow scopes, yes; at scale, expensive. Kafka transactions can give exactly-once semantics within a single Kafka cluster — read from a topic, process, write back to another topic, commit offset, all atomically — useful for stream-processing pipelines that stay within Kafka. As soon as the side effect leaves Kafka (writing to a database, calling an external API, sending a notification, decrementing inventory) the exactly-once guarantee no longer holds because the external system has no part in the Kafka transaction. The honest framing: build for at-least-once with consumer-side idempotency; reserve exactly-once for the narrow Kafka-to-Kafka case where it actually applies. Architects who treat exactly-once as a universal free guarantee corrupt state in production when the side effect crosses the Kafka boundary.

Q: What is a dead-letter queue and when do I need one?

A dead-letter queue (DLQ) is a separate topic or queue where unprocessable events accumulate with their failure metadata for human or automated review. Events end up in the DLQ when a consumer fails to process them after a configured retry count — parse errors, schema mismatches, business-rule rejections, persistent downstream failures. Without a DLQ the alternatives are equally bad: silently dropping the event (data loss, no audit trail) or repeatedly retrying forever (the consumer is blocked, partition lag grows, pipeline freezes). Configure DLQs on every consumer with monitoring (alert on DLQ depth above a threshold), retention long enough for investigation (14-30 days typical), and a documented redrive workflow (how to fix the cause and re-inject the event into the main pipeline). DLQ depth is a leading indicator of producer or consumer bugs.

Q: How do I choose the partition key and partition count?

The partition key determines ordering and parallelism. Choose a key that preserves ordering where it matters (events for the same order arrive in order at the inventory service — partition by order ID) without creating hot partitions (one heavy user routing 80% of traffic to one consumer). Common keys: entity ID (order, user, account), tenant ID for multi-tenant systems, composite keys (user ID plus entity type) when single fields concentrate badly. For partition count: estimate peak per-consumer throughput (events per second one instance can process), divide target peak throughput by per-consumer rate, double the result for headroom. Under-partitioning caps consumer-group concurrency; over-partitioning increases broker metadata cost and slows rebalancing. Resharding partitions is operationally non-trivial so over-provisioning slightly is the safer error.

Q: How does event-driven architecture compose with the Outbox, Saga, and CQRS patterns?

They are the canonical companions. Outbox is how producers reliably publish events without dual-write inconsistency between their database and the broker — the event is written to an outbox table in the same database transaction as the state change, and a separate process reliably forwards the outbox to the broker. Saga uses events as the messages between saga steps; in choreography-style sagas events are the only coordination mechanism, in orchestration-style sagas the orchestrator publishes events to drive each step. Cache-Aside and CQRS use events to invalidate caches and replicate state into denormalised read models — the write side publishes events, the read side consumes them to maintain materialised views. Idempotency is required for every event consumer because brokers default to at-least-once. Together these patterns form the standard toolkit for production event-driven microservices; each addresses a specific failure mode the others leave open.

Q: When should I NOT use event-driven architecture?

Three scenarios. (1) Strict synchronous request-reply user interactions where the user is waiting on the result (search queries, credit checks, payment confirmations) — the synchronous call is correct because the user needs the answer before the response returns. Use event-driven for the side effects that follow, not for the request-reply itself. (2) Very small systems with two or three services and modest traffic — the operational cost of broker, schema registry, monitoring, idempotency stores, and DLQs may exceed the architectural value. Use direct synchronous calls until the call graph or deployment-coordination cost makes event-driven favourable. (3) Strict end-to-end microsecond latency budgets (high-frequency trading, real-time bidding) — the broker hop is too expensive. Use in-process pub-sub or direct calls within tight network proximity for these cases.