Write a retry policy for a real service, then defend every number in it against a panel assigned to find the one you cannot justify.
Due: 30 April 2027 · Weight: 35%
The brief#
Choose a service, real or one you know well enough to be honest about, and write the retry policy it should have.
By week 8 you’ve seen a retry loop cause its own outage, a herd synchronise by accident, a budget replace a per-call count, two operators resend the same payout, a failure that could never have succeeded, and a breaker that has to close again as much as it has to open. A policy that only covers one of these is not a policy, it’s a fix for last week’s failure. State what retries when, how long it backs off, when the breaker trips, and how those three interact under load.
Then state the limit on each one. Backoff adds latency to requests that were about to succeed. An open breaker fails calls that would have worked. A shared budget refuses one layer the attempt it would have recovered on. Those are facts about the mechanisms rather than faults in them, and a policy that never mentions them is a policy whose author has not read it closely. The panel will go straight for whichever limit bites hardest on your service, so find it before they do.
What you submit#
A written policy, plus a short defence in the lab where a panel — your teacher and a rotating pair of classmates — challenges one part of it. The written document is marked on its own; the defence is marked on how you respond to the actual challenge raised, not on how well the policy was rehearsed beforehand.
Why the policy outweighs the defence#
The policy carries the most marks because it is the artefact that has to work. The defence carries fewer because it tests something narrower: whether you can explain a decision you made, rather than one you are seeing for the first time.
The spec
The brief poses the problem and leaves room for a response. The spec is the fixed part: what a marker checks. Some lines can be checked mechanically; the rest call for judgement.
- the policy names a real service and covers what happens on failure end to end, not one mechanism in isolation
- it states a retry budget, a backoff strategy and a breaker condition, and says how they interact
- every mechanism it adopts states its own limit: what that mechanism does to requests that would have succeeded without it, or what it needs from the client to work at all
- it names at least one alternative design it rejected, and why
- the defence responds to the specific challenge raised, not a rehearsed answer prepared in advance
How it is marked
| Criterion | Weight |
|---|---|
| The policy itself | 40% |
| Justification against the alternatives it rejects | 35% |
| Handling of the panel's challenges | 25% |