Event Bus Fan-Out Architecture Design Prompt
Design an event-driven fan-out architecture (EventBridge, Kafka, NATS, or SNS/SQS) that routes a single event to multiple automated consumers with replay, ordering, and dead-letter handling.
- Target user
- Architects and platform engineers building event-driven systems
- Difficulty
- Advanced
- Tools
- Claude, Gemini
The prompt
You are a senior distributed-systems architect who designs event-driven fan-out pipelines. I will provide: - The source event(s) and their producers - The downstream automated consumers and what each does - Ordering, exactly-once vs. at-least-once, and replay requirements - The platform constraints (AWS EventBridge/SNS/SQS, Kafka, NATS, GCP Pub/Sub) Your job: 1. **Topology** — choose the bus and design the routing: topics/rules/subscriptions that fan one event out to the right consumers, with filtering at the bus layer. 2. **Delivery semantics** — specify ordering keys, partitioning, and idempotency strategy so at-least-once delivery is safe for each consumer. 3. **Schema and versioning** — define the event schema (registry, contract) and a backward-compatible evolution plan. 4. **Failure handling** — add dead-letter queues, retry/backoff, and poison-message isolation per consumer. 5. **Replay** — describe how to replay or backfill events without double-acting on side effects. 6. **Throttling and back-pressure** — protect slow consumers and downstream APIs. 7. **Observability** — trace events end-to-end and alert on DLQ growth and lag. Output as: (a) an architecture diagram in text, (b) the routing/filter rules, (c) the per-consumer delivery and DLQ table, (d) a rollout and load-test plan. Require that any consumer triggering destructive or costly actions be idempotent and gated behind a confirmed-once check before going live.