ADR-0003: EventBridge as the default cross-team event backbone

• Status: Accepted (worked example)
• Date: 2026-10-23
• Deciders: Platform architecture, three product teams that publish domain events

Context and Problem Statement

Product teams increasingly integrate by calling each other’s APIs synchronously. That couples their availability and releases, merging their services into one architecture quantum in practice. Several teams want to publish domain events (“order placed”, “customer updated”) that other teams can react to. Each team is in its own account (ADR-0001).

What should be the standard way to publish and consume events across teams and accounts?

Decision Drivers

• Evolvability: consumers should be added without changing producers; event contracts must be able to evolve safely.
• Self-service: a team can publish or subscribe without a ticket to the platform team.
• Security and auditability: cross-account access is explicit, and events can be traced and replayed.
• Low operational effort: most teams don’t have streaming expertise.
• Some future use cases may need high-throughput, ordered streams.

Considered Options

1. Amazon EventBridge: event buses with content-based routing rules, cross-account delivery, a schema registry, and archive and replay.
2. Amazon MSK (managed Apache Kafka): a shared streaming platform.
3. SNS topics with SQS queues (fan-out per producer).

Decision Outcome

Chosen option: 1, EventBridge as the default for cross-team domain events, because it gives content-based routing, cross-account delivery, schema discovery, and archive and replay with almost no operational effort.

How it’s used:

• Each producing domain owns an event bus in its own account and publishes there. Consumers create cross-account rules, approved through the producer’s bus policy. There’s no single central bus that every team depends on.
• Event schemas are registered and documented. Changes must be backward compatible; breaking changes use a new event version (expand and contract).
• Every rule target has a dead-letter queue.
• MSK isn’t ruled out. A workload that needs high-throughput ordered streaming or long retention can propose a separate ADR. SNS + SQS remains fine inside a team’s own boundary.

Consequences

• Good: Producers don’t know about consumers, so new consumers don’t change producers.
• Good: Archive and replay helps with recovery and with onboarding new consumers.
• Bad: Delivery is at least once with no ordering guarantee, so consumers must be idempotent and must not rely on order.
• Bad: Event payloads are size-limited, so large data goes by reference (for example, an S3 location).
• Bad: Event-driven flows are harder to trace end to end; this needs tracing and an event catalogue.

Confirmation

• A pipeline check compares each schema change with the registered version and fails on breaking changes.
• Every EventBridge rule target has a dead-letter queue (AWS Config custom rule or IaC policy check).
• Every event bus and rule has an owner tag.
• Consumer contract tests run against sample events from the producer.
• A periodic review flags new synchronous calls between teams where an event would fit (a manual, temporal fitness function).

Pros and Cons of the Options

1. EventBridge

• Good: Content-based routing, cross-account buses, schema registry, archive and replay; serverless.
• Bad: At-least-once, unordered delivery; payload size limits; throughput limits per account and region need checking against service quotas.

2. Amazon MSK

• Good: Ordered partitions, high throughput, long retention, large ecosystem.
• Bad: Requires Kafka expertise to run and to use well; capacity and cluster management (even when managed); a shared cluster becomes a coupling point.

3. SNS + SQS

• Good: Simple, cheap, well understood; SNS FIFO with SQS FIFO gives ordering where needed.
• Bad: Routing logic lives in subscription filters per topic; no built-in schema registry or archive and replay; each producer manages its own topics.

More Information

Revisit when:

• a workload needs ordered, high-volume streaming or long event retention (separate ADR for MSK or Kinesis);
• EventBridge throughput quotas or costs become a constraint for a major domain;
• teams consistently struggle to trace event flows despite tooling.

Related: architecture styles: event-driven, ADR-0004.

Sources: AWS decision guide Amazon SQS, Amazon SNS, or Amazon EventBridge?; AWS, EventBridge and SNS compared; cloudonaut, EventBridge versus SNS.