ABC Corp is a fictional company. Every name, number and date is invented. This is a reference artifact generated with an LLM coding agent; the brief that produces it is at the bottom of this page.
Six downstream consumers (customer portal, mobile push, e-mail dispatch, CRM sync, warehouse ops, analytics)
currently learn about order-status changes by polling the orders database through the read replica
introduced in ADR-009. Polling now accounts for roughly 38% of read load on the replica, and because the consumers
poll on a 15-minute cycle, customers see status updates up to 15 minutes late, the single biggest source of
"where is my order" contact-centre tickets in the Lighthouse baseline study (≈ €210k/yr handling cost, fictional figure).
Two more consumers are planned for Q4 2026. The polling pattern does not scale and couples every consumer to the
orders schema; a schema migration in May required coordinated changes in five consumer teams.
Run our own Kafka cluster on the existing container platform. Full control over configuration, retention, and placement; we operate brokers, upgrades, and on-call ourselves.
Use the cloud provider's managed event-streaming service (Kafka-compatible API) in our EU region. Provider operates brokers; we own topics, schemas, and access control.
Publish status changes onto the existing task queue (point-to-point) with a fan-out exchange per consumer. No new infrastructure, but the queue was not designed for replayable, ordered event streams.
| Criterion (weight) | A · Self-managed Kafka | B · Managed streaming | C · Extend queue |
|---|---|---|---|
| Operational burden (×3) | own brokers + on-call | provider-operated | existing platform |
| Latency (×3) | sub-second | sub-second | no replay; backlog risk |
| Cost / yr (×2) | ≈ €260k incl. ops effort | ≈ €120k usage-based | ≈ €70k + rework later |
| Residency control (×3) | fully in-platform | EU region pinning | existing controls |
| Team familiarity (×2) | no broker ops experience | Kafka API known, service new | daily use today |
| Exit risk (×1) | open protocol | Kafka-compatible API eases exit | already owned |
| Weighted total (max 70) | 48 | 56 | 52 |
We will adopt Option B, the managed event-streaming service, for order-status notifications.
It scores highest on the criteria that drove this ADR: it removes the 15-minute polling latency and the replica load without making the order-gateway team a broker-operations team, which Option A would require and which the team's on-call capacity cannot absorb before the Q4 consumer onboarding. Option C is cheapest today but fails the latency and replay requirements: consumers that miss messages would be back to polling for reconciliation, which recreates the problem we are solving. The Kafka-compatible API keeps exit risk acceptable: producers and consumers are written against the open protocol, so a later move to self-managed (Option A) remains a configuration change, not a rewrite. EU region pinning satisfies the residency requirement recorded in the Lighthouse data-handling guideline DHG-7 (internal, fictional).
Current state: six consumers poll the orders read replica on a 15-minute cycle.
| Proposed by | R. Okafor (order-gateway tech lead) · draft circulated to consumer teams | 18 May 2026 |
| Reviewed by | A. Kowalczyk (platform), S. de Wit (data & residency) · architecture guild session, comments resolved in order-gateway#391 | 27 May 2026 |
| Accepted by | P. Mehta (head of engineering) · ADR-009 marked superseded the same day | 5 Jun 2026 |
Review date: revisit by 5 Dec 2026 (six months after acceptance), or sooner if the cost estimate (≈ €120k/yr) is exceeded or a second region is required.
Create ADR-014 'Event streaming for order-status notifications' as one HTML file: context, three options with a weighted criteria table, the decision and rationale, consequences (positive/negative/neutral), and an inline SVG diagram with a current-state/target-state toggle. It will live in the repo next to the code, so one self-contained file, no images.
Paste the brief into any capable LLM: GPT, Claude, Gemini, Grok, DeepSeek, or the assistant your company
provides. Iterate a few rounds on layout and content until it reads well. Save the final answer as a
.html file and open it in any browser. Expect similar output, not identical: every model has its
own taste, and that is fine.
This reference artifact was built with Claude Code, an LLM coding agent, over several iterations. Treat it as the bar to aim for, not as a guaranteed first answer. All data on this page is fictional.