Conclusion

EDA — decision checklist

EDA is a tool for fan-out, temporal decoupling, and replayable facts — not a personality for every integration. Suitability beats fashion.

When to use

• One fact must trigger multiple independent reactions.
• Producer must not wait on slow/fragile downstreams.
• You need audit/replay or new consumers later.
• You will fund lag, DLQ, schema, and outbox operations.

When NOT to use

• Immediate, authoritative response required.
• Strong consistency across read-after-write UX without extra machinery.
• Single consumer pool doing one job — a queue or RPC is simpler.
• Team cannot run a broker platform safely.

Eight-line design checklist

Each line answered once for the chapter's running example — photo upload — so the checklist is a demonstrated method, not a list:

1. What is the event (fact) vs command? [PhotoUploaded — past-tense fact; the UI's upload call itself stays a command.]
2. Queue, pub-sub, or retained log — which primitive? [Retained log — four consumer groups plus replay for new consumers.]
3. Delivery semantic (default at-least-once) + idempotency keys? [At-least-once + dedup on event_id.]
4. Outbox/CDC for DB+publish atomicity? [Outbox row in the upload service's DB transaction; relay/CDC publishes.]
5. Partition key for ordering needs? [Key by photo_id (or user_id) so upload/delete stay ordered.]
6. Lag SLO and who owns consumer scaling? [Feed lag SLO 2 s p99; the feed team owns its consumer scaling.]
7. DLQ policy + replay runbook? [DLQ after 5 attempts; runbook re-drives from the DLQ topic.]
8. Schema evolution rules (backward compatible)? [version field + registry; backward-compatible additions only.]

Top production alerts

1. Consumer lag above SLO (per partition).
2. DLQ depth / age.
3. Producer error rate + outbox unsent age.

Compose with other patterns

• Saga — multi-step consistency on top of events/commands.
• Outbox — reliable emission after state change.
• CQRS — projections from event streams.
• Circuit breaker / bulkhead — still needed on any remaining sync edges.

Drill ladder

1. Q: When is EDA elegant, and when is it harmful? A: Elegant for fan-out of async facts; harmful when used to dodge a synchronous correctness need or without funding lag/DLQ/schema operations.
2. Q: Why can debugging be harder than RPC? A: Causal chain spans time and services; need correlation IDs and event traces, not one stack.
3. Q: One metric that says "EDA is failing the business"? A: Billing lag hours behind RideCompleted, or checkout missing downstream side effects with growing outbox.

Takeaway

Publish facts reliably (outbox), consume idempotently (at-least-once), observe lag, and do not event-wash problems that need a synchronous answer.

I just read a lesson on **Conclusion** (System Design) and want to truly understand it. Explain Conclusion from first principles using ONE vivid real-world analogy and a visual mental model — draw it as ASCII art or a clear step-by-step diagram — with a concrete example using real numbers. Then ask me one question to check I got the mental picture, and wait for my reply. If you're unsure or a claim isn't standard, say so and reason from first principles instead of guessing.

Teach me **Conclusion** interactively. Ask me ONE guiding question at a time, wait for my answer, and adapt to my confusion — build the idea with me step by step instead of explaining it all at once. If you're unsure or a claim isn't standard, say so and reason from first principles instead of guessing.

Quiz me on **Conclusion** with 5 questions, easy to tricky, ONE at a time. Tell me if each answer is right; at the end, explain clearly what I got wrong and why. If you're unsure or a claim isn't standard, say so and reason from first principles instead of guessing.

Help me remember **Conclusion** for the long term: give the one-sentence intuition, a memorable hook/mnemonic, a tiny worked example, and 3 active-recall flashcards (Q -> A). If you're unsure or a claim isn't standard, say so and reason from first principles instead of guessing.