Event-Driven Architecture

An architectural style in which services communicate by emitting and consuming events via a message broker, rather than calling each other directly over synchronous APIs. The producer publishes an event and moves on; consumers react when ready; neither side knows about the other's existence. In ecommerce, EDA addresses the core scaling problem: how do you coordinate work across order management, inventory, loyalty, payments, and logistics without coupling those services so tightly that a slow downstream system brings down checkout?

---

How it works

In an event-driven system a service publishes an event to a broker; the broker delivers the event to any subscribers that have registered interest; the publisher does not know who the subscribers are, how many there are, or whether any of them succeed. Subscribers can come and go independently (Encore.dev, 2026-05-04).

EDA and request-response are complementary, not opposed. Most production systems use both. The right question is which to use for which interaction: EDA fits when the producer's job is finished before consumers' work begins (e.g. after an order is placed, the order service has nothing more to do — sending the confirmation email, updating inventory, and notifying the warehouse are all consumer concerns); request-response is the right model when service A needs service B's answer to continue (e.g. charging a credit card and waiting for an authorisation code) (Encore.dev, 2026-05-04).

EDA is most associated with microservices because it solves the coordination problem microservices create — how do you coordinate work across many services without coupling them tightly — but EDA and microservices are separate concepts (Encore.dev, 2026-05-04).

---

Core patterns

Saga Pattern

Coordinates long-running, multi-step business processes across services without distributed transactions; each step publishes an event indicating success or failure, and compensating events undo earlier steps when something fails downstream (e.g. a booking saga: reserve seat → charge card → send confirmation; if the charge fails, a compensating event releases the seat) (Encore.dev, 2026-05-04).

Two Saga implementation styles dominate — choreography (each service decides what to do based on events it observes) and orchestration (a coordinator service issues commands and reacts to results); choreography is simpler at small scale, orchestration is easier to reason about as the saga grows (Encore.dev, 2026-05-04).

Outbox Pattern

Fixes the dual-write bug (database commits but event publish fails) by writing the event into an outbox table inside the same database transaction as the state change; a separate process polls and publishes pending events. The atomicity of the database guarantees that either both happen or neither does (Encore.dev, 2026-05-04). See Outbox Pattern for a dedicated page.

CQRS (Command Query Responsibility Segregation)

Splits the write path from the read path — commands change state by emitting events; queries read from purpose-built read models kept up to date by consuming those events — allowing read and write models to scale and evolve independently (Encore.dev, 2026-05-04).

CQRS adds eventual consistency between writes and reads; projection lag — delays between a command completing and the projection reflecting it — can be milliseconds under normal conditions but seconds or minutes under load (JavaCodeGeeks, 2025-10, stale-risk).

See CQRS for a dedicated page.

Event Sourcing

Stores every state change as an immutable event in an append-only log; current state is derived by replaying events; the event log is the source of truth and database tables are projections (Encore.dev, 2026-05-04). See Event Sourcing for a dedicated page.

---

Platform support: what the primary vendors ship (as-of 2026)

Shopify — Next Generation Events (developer preview, 2026-05-27)

Shopify launched "Next Generation Events" in developer preview on 27 May 2026, available on the unstable API version for Product and Customer topics (more topics rolling out through 2026) (Shopify Developer Changelog PRIMARY, 2026-05-27).

Classic webhooks sent a delivery on every qualifying topic change and left relevance filtering to the app handler. Next Generation Events address three friction points: over-delivery, fixed payloads, and no built-in signal for what changed (Shopify Developer Changelog PRIMARY, 2026-05-27).

Key features:

• Field-level triggers (triggers): pre-qualify which specific field paths must change for a delivery to fire. A subscription scoped to product.variants.price does not fire on title edits, tag updates, or status changes.
• Custom GraphQL payloads (query): the developer defines the delivery payload using a standard Admin GraphQL query; Shopify runs the query at delivery time and returns the result in the data field — eliminating the follow-up API call pattern.
• Change tracking (fields_changed): every delivery includes an explicit list of field paths (with full entity paths and IDs) that triggered the event.
• Query-based delivery filter (query_filter): suppresses deliveries that don't match the current state of the query output.

Apps require Shopify CLI v3.92+ and an [events] block in shopify.app.toml. Events and classic webhooks can coexist in the same configuration (Shopify Developer Changelog PRIMARY, 2026-05-27).

commercetools — Subscriptions API + Events (public beta, 2025)

commercetools Subscriptions API delivers push notifications (at-least-once, sequenceNumber ordering, 50-subscription cap per project) to destinations including AWS EventBridge, Azure Service Bus, Google Cloud Pub/Sub, and Confluent Cloud. The API supports three payload types: Message, Change, and Event (BETA) (commercetools HTTP API docs, PRIMARY, as noted in CDC run).

In March 2025, commercetools introduced Event notifications for the Import API in public beta — adding EventSubscription and EventSubscriptionResourceTypeId types and a Set Events update action to the Subscriptions API, and six Import-specific events: ImportContainerCreated, ImportContainerDeleted, ImportOperationRejected, ImportUnresolved, ImportValidationFailed, ImportWaitForMasterVariant. This eliminates manual polling for import status (commercetools HTTP API Release Notes PRIMARY, 2025-03-28).

In May 2026, commercetools launched Platform Insights as a generally available add-on product, streaming API metrics and logs directly into APM tools (Datadog, New Relic, Dynatrace, OpenTelemetry-compatible backends) — providing visibility into commercetools platform behaviour from the project's perspective, complementing existing client-side logging (commercetools HTTP API Release Notes PRIMARY, 2026-05-20).

---

Ecommerce use cases and named retailer implementations

After an order is placed, a typical event-driven order flow: order service emits order.created → EventBridge routes it → payment processes asynchronously → loyalty service consumes from SQS at its own pace — a slow loyalty service no longer takes down checkout (AWS re:Invent CNS307 2025-12).

Named retailer implementations (all secondary attributions via Netguru, 2026-07-21):

• ASOS: leverages event-driven systems to handle flash sales, ensuring real-time demand signals don't bottleneck the entire infrastructure.
• Ocado: uses EDA to update inventory in real time as shoppers place items in baskets, preventing overselling at scale.
• Allegro (one of Europe's largest marketplaces): event-driven patterns allow microservices to scale elastically during sudden activity surges.
• Farfetch: adopted EDA to plug AI-powered recommendations into the customer journey without destabilising core commerce flows.
• Flipkart: event-driven flows maintain high availability during mega-sale events; if one service stalls, others continue.
• Mercado Libre: invested heavily in event deduplication and consistency mechanisms to prevent order mismatches — without this rigour, customer trust can evaporate.
• Rakuten: built data lineage and auditability governance frameworks early to ensure regulatory compliance across distributed systems.

[!unverified] All named-retailer implementations above are second-hand attributions via Netguru (2026-07-21), which cites Allegro tech blog (2024) and Mercado Libre 2024 impact report. No direct primary engineering post was retrieved for ASOS, Ocado, Farfetch, Flipkart, or Rakuten. Treat as directionally useful, not primary-evidenced.

LEGO (pre-2024, stale-risk): experienced ecommerce transaction spikes of up to 200× and user traffic spikes of up to 9.5× during peak sales events; resolved this by refactoring their monolithic platform to a serverless event-driven approach on AWS (AWS for Industries blog, 2023-05-15).

---

Operational risks and complexity costs

• At-least-once delivery: most brokers guarantee this, meaning consumers will sometimes see the same event twice; every consumer must be safe to re-run via idempotency keys, dedup tables, or naturally idempotent operations (Encore.dev, 2026-05-04).
• Ordering: strict global ordering is rarely available and rarely free; most systems get partition-level ordering at best — events must be designed so ordering matters within a key (one user's events) but not across keys (Encore.dev, 2026-05-04).
• Dead-letter queues: essential for catching events that consumers repeatedly fail to process; without them, a single bad event can stall a subscription forever (Encore.dev, 2026-05-04).
• Schema evolution: events outlive the code that wrote them; a consumer reading an event published a year ago must not break because someone renamed a field; Schema Registry (Avro, Protobuf with backward-compat checks) or strict additive-only conventions are the usual answer (Encore.dev, 2026-05-04).
• Observability: debugging across multiple services and time windows requires distributed tracing — not optional (Encore.dev, 2026-05-04).
• Governance and compliance: asynchronous data flows across dozens of microservices increase GDPR and PCI DSS complexity, especially for payment data and personal identifiers (Netguru, 2026-07-21).

The "distributed big ball of mud" failure mode

Over 10 years speaking to hundreds of companies, David Boyne (NDC London 2025) found that almost all fall into three problems: a distributed big ball of mud, lack of event design (too much coupling), and lack of discoverability (NDC Conferences, 2025-03).

As the barrier to entry for EDA lowers, organisations build producer-consumer relationships without defined domains, exposing implementation details in events and losing control of who consumes what. Most organisations apply strong API versioning and documentation discipline (OpenAPI, naming conventions) but treat event design as "a free for all" — implementation details leak into event payloads, breaking changes propagate silently (NDC Conferences, 2025-03).

Boyne's prescribed fixes: use EventStorming or EventModeling to design before building; adopt CloudEvents as a standard schema; use AsyncAPI or EventCatalog (his open-source tool) to make architecture discoverable (NDC Conferences, 2025-03).

By December 2025, Boyne estimated that event-driven architecture documentation is 10–15 years behind API documentation, with most organisations lacking machine-readable specifications for their events (NDC Conferences / Compiled Conversations podcast, 2025-12).

---

---

Broker landscape (as-of 2026-05)

A common misstep is picking Kafka because it's the brand-name option when SNS+SQS or NATS would solve the problem with a tenth of the operational overhead; the broker should match actual volume and patterns, not imagined future scale (Encore.dev, 2026-05-04).

Broker	Category	Best for
Kafka / Confluent	Log-based, high throughput	Event sourcing, audit logs, high-volume retail
Redpanda	Kafka-compatible, single binary	Simpler ops than Kafka, same API
NATS/JetStream	Lightweight, low latency	IoT/edge, simple fan-out
RabbitMQ	Traditional AMQP	Mature routing, enterprise queuing
AWS EventBridge	Managed, SaaS integration	Rule-based routing, schema registry
AWS SNS+SQS	Simple, cheap	Practical AWS default for fan-out + queue
GCP Pub/Sub	Push/pull, ordering keys	Google Cloud native
Azure Service Bus / Event Grid	Enterprise, transactions	Microsoft stack, session ordering

(Encore.dev, 2026-05-04)

commercetools Subscriptions API supports AWS EventBridge, Azure Service Bus, Google Cloud Pub/Sub, and Confluent Cloud as destinations (as-of 2026).

---

When NOT to use EDA

Encore.dev (2026-05-04) explicitly cautions against EDA when the system is small and the team is small — "you're paying complexity tax for benefits you won't use."

---

Key terms

Term	Meaning
Event	An immutable record that something happened (e.g. order.created, inventory.updated)
Producer / Publisher	The service that emits an event
Consumer / Subscriber	The service that reacts to an event
Broker	The intermediary that stores and delivers events (Kafka, SQS, EventBridge, etc.)
Choreography	Saga coordination where each service reacts to events independently — no central conductor
Orchestration	Saga coordination where a central service issues commands and handles results
Idempotency	A consumer operation that produces the same result regardless of how many times it's applied
Dead-Letter Queue (DLQ)	A holding queue for events that repeatedly fail to process
Schema Registry	A service that enforces and versions event payload schemas (Avro, Protobuf)
CQRS	Command Query Responsibility Segregation — separate write and read models
Event Sourcing	Storing all state changes as events; current state derived by replaying the log
Outbox Pattern	Dual-write fix: write event to outbox table in same DB transaction as state change
Projection lag	Delay between a command completing and the CQRS read model reflecting it

---

Frontier links

The following concepts are referenced in this page and related pages but do not yet have their own dedicated pages:

Saga Pattern · Outbox Pattern · CQRS · Event Sourcing · Schema Registry · CloudEvents · AsyncAPI · EventStorming · EventModeling · AWS EventBridge · Apache Flink