Module 3: Event-Driven Architecture: Mistake Clinic

This clinic turns wrong moves into reusable judgment. Use it after each practice page and again before the quiz or checkpoint.

---

Module-Specific Mistake Radar

Start with these traps. Replace or extend them with real mistakes from your own work.

Mistake to look for	Where it shows up	Symptom	Repair evidence
Finishing Event Modeling Lab with only a final answer	Event Modeling Lab	The work has no failed case, trace, test, proof gap, or design stress point.	Add the smallest broken example and show the repair that changes the result.
Finishing Messaging Patterns Workshop with only a final answer	Messaging Patterns Workshop	The work has no failed case, trace, test, proof gap, or design stress point.	Add the smallest broken example and show the repair that changes the result.
Finishing Saga and Idempotency Clinic with only a final answer	Saga and Idempotency Clinic	The work has no failed case, trace, test, proof gap, or design stress point.	Add the smallest broken example and show the repair that changes the result.
Finishing Event-Driven Katas with only a final answer	Event-Driven Katas	The work has no failed case, trace, test, proof gap, or design stress point.	Add the smallest broken example and show the repair that changes the result.
Treating An Event Is an Immutable Fact About the Past as vocabulary instead of a tool	An Event Is an Immutable Fact About the Past	The explanation names the concept but cannot decide between two cases.	Write one example, one non-example, and the rule that separates them.
Treating Events vs Commands vs Requests as vocabulary instead of a tool	Events vs Commands vs Requests	The explanation names the concept but cannot decide between two cases.	Write one example, one non-example, and the rule that separates them.

---

Practice Mistake Checks

Pull any miss from these checks into your mistake log.

Event Modeling Lab

Source: practice/01-event-modeling-lab.md

For each statement, name the error and give the corrected form:

1. "We publish SendWelcomeEmail to Kafka because it is an event-driven system."
2. "Our event is OrderUpdated with a payload of the new order state."
3. "We republish the same event with a correction when we find a bug in the payload."
4. "Every database UPDATE in our service becomes a domain event."
5. "Our event payload is just {'order_id': '...'} because the consumer can query back for details."
6. "We name our event topic orders and put creates, updates, deletes, and queries on it."

Messaging Patterns Workshop

Source: practice/02-messaging-patterns-workshop.md

For each, name the error and the correct alternative:

1. "We use SQS standard to broadcast OrderPlaced to three services, and we get duplicates, not broadcast."
2. "We have 20 subscribers on user-signed-up, all doing 'send welcome email' with small variations."
3. "Our event carries the full user record, including the password hash."
4. "We INSERT INTO orders then kafka.produce(...) in the same Python function, and sometimes events go missing after a crash."
5. "We publish the event in the same thread as the HTTP response, so the customer sees the confirmation page faster."
6. "We delete outbox rows immediately on successful publish to keep the table small."
7. "Our outbox relay publishes, then updates published_at, and sometimes we see duplicate events -- bug?"

Saga and Idempotency Clinic

Source: practice/03-saga-and-idempotency-clinic.md

For each, name the error:

1. "We retry failed commands until they succeed, so we don't need idempotency."
2. "Our compensation function reverses the previous DB transaction."
3. "We use Kafka EOS, so our DB writes are exactly-once."
4. "Our saga's compensation for PaymentCaptured is a new PaymentCaptured with negative amount."
5. "Our saga has pending, completed, failed states -- looks complete."
6. "The dedup cache has a 60-second TTL because messages are fast."
7. "Our orchestrator retries indefinitely; no need for timeouts."
8. "We do not need idempotency keys on Stripe because we call it only once."

---

Repair Protocol

For each real mistake:

1. Reproduce the failure on the smallest example, trace, proof, query, command, or design sketch.
2. Name the hidden assumption.
3. Repair the artifact.
4. Save evidence that changed: failing then passing test, corrected proof step, revised diagram, safer command, benchmark, or review note.
5. Add one retrieval card beginning with Check... before... or Do not use... when....

---

Mistake Log

Date	Mistake	Symptom	Root cause	Repair evidence	Retrieval card
Starter	Pick one radar row above	Explain how it would fail in this module	Name the assumption	Add a counterexample or corrected artifact	Write the card before closing the page

---

Completion Standard

• At least five real mistakes are logged.
• At least two mistakes include a counterexample or failing test.
• At least one mistake connects to an older semester skill.
• At least one correction changes code, a proof, a diagram, a command transcript, a query, or a design decision.