The Professor
Stack: The whole course · Project: TicketFlow complete Status: Published — the backend's defense and the simulated postmortem Prerequisite: Lesson 56 — Compliance
Objectives
- Consolidate TicketFlow as a finished product: the complete system with its guarantees, its observability and its documentation.
- Defend the project: the technical presentation (the why of every decision) and the business pitch (51) for two audiences.
- Survive the simulated postmortem: the unexpected incident the exam injects and your response with 47's method.
1. The exam's scope: what gets defended
The final project is not "write more code": it is DEFENDING what the course built. The three parts: (1) the technical defense (30 min): the system's tour with the ADRs — the why of the lock (10), the outbox (25), the saga (32), the partial DDD (52), the modular monolith (53); every decision with its trade-off and its review trigger; (2) the business pitch (10 min): 51's money map and the jargon-free translation — the business owner must understand what they bought; (3) the simulated postmortem (30 min): the injected incident (§4) solved live with 47's protocol.
The defense's material (what gets submitted): the complete repo (code + tests + pipeline), the docs (48's onboarding, 47's runbook, 56's map), and the final one-pager: the system map (55) with the 10 business guarantees.
2. The 10 guarantees: the list answering "what did I buy?"
The whole course's synthesis in the list the exam verifies (each guarantee with its lesson and its test):
| # | Guarantee | Lesson | The test insuring it |
|---|---|---|---|
| 1 | One seat, one winner (any concurrency) | 10 | the N=10 test (34) |
| 2 | No domain event gets lost (outbox) | 25 | the atomicity test (34) |
| 3 | Money never moves twice (idempotency + saga) | 14/32 | the resumable saga (34) |
| 4 | Every error is a problem+json with trace_id | 26 | assert_problem (35) |
| 5 | Config is the environment; the image is one | 27/40 | the same image ×3 (27) |
| 6 | Every changed contract breaks a test before the front | 35 | the contract guard (28) |
| 7 | The presale peak degrades with grace and recovers | 36/54 | 54's game day |
| 8 | Every incident is diagnosable in <15 min | 45/46 | 46's game day |
| 9 | Every decision has its ADR with a review trigger | 48 | the ADR index |
| 10 | Personal data has a basis, retention and rights | 23/56 | the internal DPO (56) |
The defense walks the list: each row is 2 minutes of "what it guarantees, how, and where the proof is". The examiner (the professor, a colleague, or yourself in 6 months) picks 3 rows at random and demands them with demo.
3. The technical defense: the format that teaches
The defense's format (30 min, the course's method): (1) the REQUEST's tour (the checkout end to end: HTTP → layers (24) → TX (10) → outbox (25) → saga (32) → queue (29) → email — 32's story with the real system); (2) the FAILURE's tour (the breaker (54), the UNKNOWN (32), 47's postmortem: the system defended by what it does when it hurts); (3) the 3 most-argued ADRs (the examiner asks "why not K8s? why not Kafka? why partial DDD?": the answers are the ADRs with their triggers). The exam's rule: the answer "I don't know, but here's how I'd find out" (37/47's method) scores HIGHER than the bluff — the craft is the method, not the memory.
4. The simulated postmortem: the injected incident
The exam injects ONE unannounced incident (the examiner's pool): (a) the gateway responds slowly (5 s) during the peak; (b) the outbox gets stuck (the poller dies silently); (c) a deploy introduces an N+1 in the listing; (d) Redis fills up and evicts the cache keys; (e) a customer reports "I was charged twice" (the duplicated charge: 14's nightmare). The expected response (47's protocol LIVE): confirm (46's dash), scope (45's trace/log), mitigate (flag/rollback/breaker), locate (37's tools), explain (the postmortem in 10 min with actions). The time: 30 min with the chronology written.
The drill's preparation (exercise 3): YOU inject the 5 incidents into YOUR environment and solve them yourself with chronology — the exam is the drill done in front of witnesses. The 5 with their weapon: (a) → timeout+breaker+SLO; (b) → 46's heartbeat; (c) → 37's flamegraph; (d) → 38's FLUSHALL + the maxmemory; (e) → 14's idempotency + 08's ledger.
5. The course's close: what remains afterwards
The course ends; the craft continues. What stays installed: the system (TicketFlow with its 10 guarantees), the METHOD (measure before optimizing, the test net before the refactor, the ADR before the decision, the postmortem after the incident), and the HABITS (the fast suite on every save, the PR with self-review, the quarterly game day, reviewing the bill and the backlog with the business). The professor's final recommendation: the next project (yours, not the course's) starts with module 12's first 3 lessons in mind: domain first (52), modular boundaries from day 1 (53), the ADR from the first decision (48) — and the rest of the course as the toolbox to return to rung by rung, not from memory: the index (the site's home) IS the map.
Self-assessment
- The exam's three parts (defense/pitch/postmortem): what material does each submit and which weapon-question does the defense carry?
- Walk the 10 guarantees: which would cost you most to prove TODAY and what is it missing (the test? the runbook? the number?)?
- Why does "I don't know, but here's how I'd find out" score higher than the bluff, and which tools does that answer name?
- Of the 5 incidents in the pool: which is your worst scenario and which is ITS weapon (the timeout, the heartbeat, the ledger...)?
- Which three course habits survive the finished project, and what is the professor's final recommendation?
Continue with the exercises. The solutions only after trying it yourself.