Event-Driven Architecture in 2026: Patterns That Actually Work in Production

Event-driven architecture stopped being a hot take years ago and is now routine production infrastructure for any system above a certain scale. The interesting question in 2026 is no longer whether to use events, it is how to avoid the failure modes that have killed enough EDA rollouts to fill a conference track. This post walks through the patterns that hold up under load, the technology choices that matter, and the operational discipline that distinguishes a working event-driven system from a tangle of unreliable webhooks.

Kafka, Pulsar, NATS, or a managed broker#

The transport choice is the first real decision. Apache Kafka, particularly via Confluent Cloud, AWS MSK, and the newer KRaft-only self-managed deployments, remains the default for high-throughput durable event streams. The recent KIP-405 tiered storage work and the move away from ZooKeeper have removed the two biggest operational complaints. Apache Pulsar holds a credible position where multi-tenancy and geo-replication matter, particularly at telco and large SaaS workloads, with Kesque and StreamNative as the managed options.

NATS, especially with JetStream, has become the right answer for lightweight messaging where Kafka is more machinery than the workload deserves. Sub-millisecond latency, simple cluster topology, and a model that fits microservices that mostly need request-reply and at-least-once delivery. Redis Streams remains a reasonable choice for smaller systems. AWS Kinesis, Azure Event Hubs, and Google Pub/Sub are the managed shortcuts for teams that do not want to operate brokers at all; the trade-off is vendor lock-in and per-event pricing that gets uncomfortable above roughly 50 thousand events per second.

The outbox pattern is non-negotiable#

The single most common failure we see is teams publishing events directly from application code after a database commit, then losing events when the process crashes between the commit and the publish. The transactional outbox pattern fixes this: write the event to an outbox table in the same database transaction as the state change, then have a separate process (Debezium, a dedicated relay, or a Temporal workflow) read the outbox and publish to the broker. This guarantees at-least-once delivery with the same durability as the underlying database. Combined with idempotent consumers, it removes an entire category of three-am incidents.

Eventual consistency is a UX problem, not just a technical one#

The honest trade-off of EDA is that read-your-writes consistency goes away the moment you split a system across event boundaries. A user who updates their profile and immediately reloads the page may not see the change because the read model has not caught up. The technical mitigations, write-through caches on the command side, sticky reads, version tokens that the client passes back, are all useful, but the more important shift is admitting in the product design that some screens will display stale data for a few hundred milliseconds. Teams that build EDA without telling product and design about this consistently end up rewriting it.

Saga, choreography, orchestration: pick on purpose#

The saga pattern coordinates distributed state changes through a sequence of events plus compensating actions for failure. The choreography flavor has each service react to events and publish its own; the orchestration flavor has a central coordinator drive the sequence. Choreography wins on coupling but loses on observability and debuggability. Orchestration wins on clarity but reintroduces a coordination point that needs its own reliability story.

In 2026 the orchestration option is dramatically better than it used to be. Temporal has become the default for any multi-step workflow that needs durability, retries, and human-readable execution history. AWS Step Functions covers the AWS-only case. Camunda 8 and Conductor remain credible for BPMN-heavy environments. Most healthy production systems mix both styles: choreography for loosely coupled domain events, orchestration via Temporal or Step Functions for long-running business processes like onboarding, refunds, or multi-leg payments.

Event sourcing and CQRS, used selectively#

Event sourcing, persisting the sequence of events as the system of record, is powerful for audit, time travel, and replayable read models. It is also genuinely harder to operate than a normal write-then-read system, particularly around schema evolution and snapshotting. The 2026 consensus is to use event sourcing selectively for the bounded contexts that benefit, typically ledger, audit-heavy regulated domains, and any system where you need to replay history into a new read model, rather than across the whole architecture. CQRS, splitting the write model from one or more read-optimized models, pairs naturally with event sourcing but is also useful on its own.

Schema management and the operational checklist#

The biggest distinguisher between healthy and unhealthy EDA is schema discipline. Confluent Schema Registry, AWS Glue Schema Registry, or Buf for Protobuf are not optional at scale. Compatibility rules (backward, forward, full) need to be enforced in CI, not at deploy. Beyond schemas, the operational checklist is short and unforgiving: idempotent consumers everywhere, dead-letter queues with replay tooling, distributed tracing through the broker (OpenTelemetry semantic conventions for messaging are finally good enough), and explicit versioning of event types from day one.

Where pdpspectra fits#

Our cloud infrastructure practice and data engineering practice build EDA systems for production deployments, including Kafka and Temporal rollouts, outbox-pattern retrofits, and the schema governance that keeps these systems honest.

Related reading: the Temporal workflow engine post, the streaming data Flink vs Kafka post, and the microservices vs monolith post.

---

Event-driven architecture requires discipline. Talk to our team about your architecture.