Milestone map
Milestone map
3 milestones
Design a distributed system with explicit trade-off analysis
4 weeks
Choose a real system design problem — a URL shortener handling 10 billion clicks/month, a ride-sharing dispatch backend, a rate-limiting service for an API gateway, or a time-series metrics store — and produce a full system design document. Cover: functional and non-functional requirements, back-of-envelope capacity estimation, a component architecture diagram, the choice of data stores (with justification), consistency and availability trade-offs under CAP, and at least two design alternatives with their trade-offs compared.
Proof required
System design document (800+ words) covering requirements, capacity estimation, component architecture diagram, data store choices with justification, CAP trade-offs, and two alternative designs with explicit comparison.
What gets checked
- Capacity estimation uses real numbers (QPS, storage per record, network bandwidth) — not 'it needs to scale'
- Data store choices are justified by access patterns — not 'use Postgres for relational data'
- Two genuine alternative designs are compared with explicit trade-offs — not variations of the same architecture
Common mistakes
- Writing a design that solves the happy path without addressing failure modes — a production system design must answer 'what happens when the message queue goes down?' or 'what happens when the cache is cold?'
- Choosing technologies by name rather than by access pattern — 'I'd use Redis here' without explaining why Redis's data model fits this use case is not a design decision
- Not quantifying scale — a design without capacity numbers cannot be evaluated for feasibility
Resources
Foundationstart here
What a verifier looks for
- Check the capacity estimation — confirm it uses specific numbers for QPS, storage, and bandwidth
- Review data store choices — confirm they are justified by access patterns, not just by type category
- Verify two alternative designs exist with explicit trade-off comparison
You'll sign in first, then come straight back here.
Design a system requiring distributed consistency or consensus
5 weeks
Produce a second system design focused on a problem requiring distributed consistency: a distributed lock, a globally consistent counter, a distributed transaction coordinator, a leader election system, or a multi-region write store with conflict resolution. Document the consistency model chosen (strong, eventual, linearisable, etc.), justify why it fits the problem, and demonstrate understanding of the failure scenarios specific to your consistency choice.
Proof required
System design document (700+ words) for a consistency-heavy problem, covering the consistency model chosen, justification for that choice, failure scenarios under your model, and explicit description of how the system behaves during a network partition.
What gets checked
- Consistency model is named specifically (linearisability, sequential consistency, causal consistency, eventual consistency) — not just 'strongly consistent'
- Partition behaviour is explicitly addressed — what happens to reads and writes when a network partition occurs
- Failure scenarios are specific to the chosen consistency model — not generic uptime concerns
Common mistakes
- Conflating 'consistency' with ACID — consistency in the CAP sense is about replica agreement, not transaction integrity
- Designing a strongly consistent system without explaining the latency or availability cost — strong consistency under partition requires refusing operations; there is no free lunch
- Not addressing partition behaviour — this is the defining challenge of distributed consistency and cannot be omitted
Resources
Foundationstart here
What a verifier looks for
- Verify the consistency model is named precisely — not a vague synonym
- Check partition behaviour is addressed specifically — not just 'handled with retry logic'
- Review failure scenarios — confirm they are specific to the chosen consistency model
You'll sign in first, then come straight back here.
Present design under novel constraint challenge to a senior engineer
1 week
Present one of the two system designs to a senior software engineer or systems architect for a live Q&A. The reviewer must introduce a novel constraint mid-review that was not in the original problem — 'now the read/write ratio inverts', 'now the service must work offline', 'now you need multi-tenancy with data isolation', 'now audit logs are legally required'. Respond to the constraint in real time and sketch the design changes needed. This live challenge is the AI-fakeability countermeasure: LLMs produce plausible-sounding designs, but adapting under novel constraint requires genuine understanding of the trade-offs.
Proof required
Q&A notes (300+ words) documenting the reviewer's background, the novel constraint they introduced, your real-time reasoning response, and the specific design changes you sketched or committed to make.
What gets checked
- Reviewer is a senior software engineer or systems architect with real distributed systems experience
- Novel constraint is documented specifically — not 'they asked some questions'
- Response documents reasoning process, not just the final design change decision
Common mistakes
- Choosing a reviewer who asks clarifying questions rather than introducing a genuine constraint — the Q&A must involve novel design pressure, not understanding confirmation
- Preparing the response to a novel constraint in advance — the point is the live cognitive load of adapting to an unforeseen requirement
- Not sketching design changes — responding 'I would rethink the architecture' without a specific direction is not a system design answer
Resources
What a verifier looks for
- Confirm the reviewer has genuine distributed systems experience — ask for a specific system they have designed or operated at scale
- Review the novel constraint — confirm it was not in the original problem and required real-time adaptation
- Check that design change sketches are specific — not a vague commitment to 'rework the architecture'
You'll sign in first, then come straight back here.