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
Powstik Guide
An 800-word design with capacity estimates and trade-offs.
Steps
- State functional and non-functional needs.
- Estimate traffic and storage.
- Draw the components.
- Explain two trade-offs you made.
Template
Requirements: Capacity estimate: Architecture diagram: Trade-off 1: Trade-off 2:
What gets sent back
- Under 800 words.
- No capacity numbers.
- Trade-offs not explained.
Resources
Foundationstart here
Depthgo deeper
Masteryfor the dedicated
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
Powstik Guide
A 700-word design for a consistency-heavy problem.
Steps
- Pick a problem needing strong guarantees.
- Choose a consistency model.
- Justify the consensus approach.
- Show what happens when a node fails.
Template
Problem: Consistency model and why: Consensus approach: Failure scenario:
What gets sent back
- Under 700 words.
- Model not justified.
- No failure case.
Resources
Foundationstart here
Depthgo deeper
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 shows the work is your own: 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
Powstik Guide
A live design review under a surprise constraint.
Steps
- Pick your stronger design and redraw it cleanly.
- Write down its main capacity numbers.
- Ask the reviewer to add a constraint you haven't seen.
- Re-estimate out loud before redrawing anything.
- Write the notes within an hour of the session.
Template
Reviewer background: Original design (one line): Novel constraint introduced: My first estimate after the change: Components that break: Changes I sketched or committed to: What I'd do with more time:
What gets sent back
- A reviewer who only asks clarifying questions.
- A constraint you prepared for in advance.
- Notes under 300 words.
Resources
Foundationstart here
Depthgo deeper
Masteryfor the dedicated
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.