DOCUMENTADR-007

ADR-007 — Event-driven order notifications

Why we chose an event bus over synchronous calls to notify downstream services.

Context
01 · Options

When an order is placed, shipping, billing, and analytics all need to know. Calling each one synchronously couples checkout to three downstreams — and they fail together.

SECTION 01 · Options

Options considered

Option 1Synchronous calls
Order service calls each downstream inline.
  • Easy to trace
  • Tight coupling
  • One slow consumer blocks checkout
REJECTED — couples checkout to downstreams
Option 2Outbox + polling
Downstreams poll an outbox table.
  • No new infra
  • Polling lag
  • The DB becomes a queue
VIABLE — kept as fallback
Option 3Event bus
Publish OrderPlaced; consumers subscribe independently.
  • Decoupled deploys
  • Independent scaling
  • Replayable
  • New infra to operate
CHOSEN
ADR-007 — Event-driven order notifications2 / 4
Context
02 · Note
SECTION 02 · Note

Decision

Success
Publish domain events to a managed event bus; downstream services subscribe independently.
ADR-007 — Event-driven order notifications3 / 4
Context
03 · Status
SECTION 03 · Trade-offs

Consequences

We gain
Decoupled deploys
Replay for recovery
Independent scaling
We accept
Eventual consistency between services
The bus is now critical infrastructure
SECTION 04 · Status
TaskStatusPriority
Stand up the managed event bus with a dead-letter queuedoinghigh
Define the OrderPlaced schema and a versioning policytodohigh
Migrate the billing consumer first as the referencetodomed
ADR-007 — Event-driven order notifications4 / 4
1 / 4
Document