Ten weeks ago you had a Python file. Today you have a distributed system with a deadline, an intelligence module inside its hot path, telemetry that explains it, and a scoreboard that does not care how clever you were — only whether the thing stayed up and earned its return without betting the account. This is the week you demonstrate that, and then explain the one time it broke.
One event bus, four core services, and five intelligence modules that plug into it as event sources. Every arrow is a typed message; every box has a latency budget and a defined way to fail.
The shape has not changed since week 3. What changed is what hangs off it: week 5 added a second venue, week 6 a detector reading the session tape, week 7 a perception service, week 8 a closed-loop controller, week 9 a watchdog and a replay recorder. None of them required rewriting the bus — which is the entire argument for the plugin registry, and the reason your bot from week 4 still runs today.
Pick a component. The diagram highlights it and its edges, and the panel tells you what it owns, which week built it, the message it puts on the wire, its budget, and how it fails. Arrow keys move along the row.
# the seam that made all five modules possible: one registry, three verbs arena.register_security("BTC-USD", price_fn=crypto_feed) # week 5 arena.register_strategy("my_bot", signal_fn=my_strategy) # week 4 arena.register_shock("fed_hike", apply_fn=my_shock_fn) # week 3 # and the rule that made the bus survive ten weeks of change await ws.send(msg.model_dump_json()) # a Pydantic model, never a raw dict msg = OrderAck.model_validate_json(raw) # a model class, never manual JSON
Because you already broke it, on purpose, in private. Five failure modes cover almost everything that goes wrong in a live session, and each has a boring, specific, testable answer.
The naive bot is not badly written — it is written for the happy path, which is the same thing. It assumes a message that arrives is fresh, an order that is sent is filled, a socket that was open is still open, and an event that arrives once arrives exactly once. Every one of those assumptions is false in a live session, and each one has a cheap fix that costs about five lines.
Pick a failure and run it down two lanes at once. Same market, same strategy, same capital — the only difference is whether the bot expected the failure.
Four teams, one cumulative return, four different rankings. The season score is published up front for exactly this reason: ranking on final net worth rewards one lucky levered bet, and that is not the behaviour a course about engineering wants to select for.
Every team below finishes the season at the same cumulative return. Move the volatility and the drawdown and watch the ranking rearrange itself — then read the formula underneath and see exactly which term did it.
P&L is the integration test, not the grade. A well-engineered system that loses money politely beats spaghetti that got lucky.
| artefact | what it proves |
|---|---|
| tagged repo | the demo and the code are the same thing |
| runbook | someone else can start it |
| latency histogram | you measured tails, not averages |
| replay bundle | the failure is reproducible |
| risk limit that fired | the limit is real, not decorative |
| post-mortem | you understand your own system |
Twelve items, weighted by how badly each one hurts when it is missing. Tick what is genuinely true right now — not what you intend to do on the morning.
Six domains, ten weeks, one loop. Pick a domain and every stage relabels itself. The shape never changes; only the budget does — and the budget is what makes it engineering rather than analysis.
None of these is a bug in your code. Open them.
No runbook, no one-command start, three terminals in a specific order, an environment variable only you know about, and a live network dependency in a room whose wifi blocks the port. The system works; the demo does not; and from the audience those are indistinguishable.
Fix: one command that starts everything, a runbook a stranger can follow, and a rehearsal from a cold boot with the network unplugged. If the demo needs the internet, record a tape and replay it.
Two days before the demo, the temptation is to turn the size up. It sometimes works, and when it works it is indistinguishable from having been right, which is precisely why it is not being graded. The scoreboard divides by volatility and penalises drawdown, so the levered bet is punished twice even when it pays.
Fix: spend those two days on the runbook, the replay bundle and the histogram. They are worth more marks and they are the parts that transfer to the job.
“Sam pushed a broken config.” That sentence ends the investigation exactly where it should begin: why could an unversioned config reach a running process, and why did nothing notice for forty minutes? The mirror-image failure is the blameless post-mortem with no evidence — a paragraph of recollection, no chart, no log, no replay.
Fix: name mechanisms, not people; attach the telemetry that proves the sequence; and add the test that would now fail. A post-mortem without a new test is a story.
No tag, uncommitted changes on the demo machine, a database that was hand-edited during the session, a config that lives in someone's shell history. Six weeks later nobody — including you — can say what was actually running when the numbers you reported were produced.
Fix: tag the commit you demo, commit the config with it, export the season state, and put the digest of the run in the report. The claim “these numbers came from this tag” should be checkable.
“Mean decision latency 4 ms.” Then, live, a p99.9 of 300 ms produces a visible stall and the whole presentation is now about the number you did not put on the slide. It is the same mistake as week 7's frame budget and week 9's deadline, arriving one last time with an audience.
Fix: put p50, p99 and max on the slide, with the miss count. It reads as confidence, it is the honest measurement, and it removes the only question you cannot answer.
Instant feedback, no grading. The last three questions of the course.
Q1Two teams finish the season up exactly 6 %. One did it with 0.3 % per-snapshot volatility and a 2 % drawdown; the other with 3 % volatility and a 30 % drawdown. Who ranks higher?
Q2Mid-session your bot receives the same fill message twice. What is the correct handling?
Q3What makes a post-mortem credible to someone who was not there?
make install — and keep it after the course: it is a working distributed system.