| name | sysdesign-interview-flow-50min |
| description | Use when approaching a new system design — a 50-minute flow (requirements → API → data model/arch → deep dive → monitoring) that doubles as a spec-authoring template. |
| category | sysdesign |
| version | 1.0.0 |
| requires | [] |
| optional_companions | [] |
When this fires
Fires on "how do I structure a system design review?", "como estruturar
uma spec técnica?", "I have 50 minutes to design X", "estamos abrindo um
desenho novo — por onde começo?", and on any fresh system design prompt
where no framework is already in play. Although the flow comes from
interview prep, it is load-bearing for real work: a team that runs this
flow for a new service ends up with a better spec than one that dives
straight into boxes-and-arrows. The skill enforces the five phases in
order, with a time budget per phase that prevents the common failure
mode — spending 40 minutes on the "fun" data model and 5 minutes on
requirements.
Preconditions
- The design is genuinely new (no prior spec, no existing service to
evolve). For incremental changes, a lighter ADR-style flow is
usually better.
- The human or team driving the design can commit 50 minutes (or a
proportional block — 25, 75, 100 minutes scale the same shape).
- A whiteboard or shared doc exists where artifacts from each phase
persist. Flow phases that produce nothing in writing are
indistinguishable from free-form discussion.
- There is a rough problem statement — one or two sentences of what
the system needs to do. Not a spec, but a seed.
Execution Workflow
- Phase 1 — Requirements (10 min, 20% of budget). Ask what the
system must do (functional) and what constraints it must satisfy
(non-functional). Delegate the non-functional half to
sysdesign-nfr-clarification if present. By the end of this phase,
the board has: 3-7 functional requirements, a first-pass answer on
scalability / availability / latency / consistency / cost, and any
assumption explicit in writing. If phase 1 takes less than 8
minutes, you did not ask enough; if more than 15, force a timebox.
- Phase 2 — API draft (5 min, 10%). Sketch the handful of
endpoints or RPCs the system exposes. REST verbs and paths, or
function signatures. Do not design auth headers or pagination
yet — just the shapes. This phase grounds the data model in what
the system actually does for its callers.
- Phase 3 — Data model + high-level architecture (10 min, 20%).
Name the entities (one line each), pick a storage shape per entity
(relational, document, KV, time-series, object store), and draw
the top-level boxes: clients, gateway, services, stores, queues.
Mark which NFR each box is there for. The diagram is chunky, not
detailed — details belong to phase 4.
- Phase 4 — Deep dive on critical components (15 min, 30%). Pick
the 1-3 components that carry the hardest NFR load (highest QPS,
tightest consistency, biggest blast radius) and zoom in. Data
partitioning, cache strategy, failure modes, and their interaction.
If the interviewer or reviewer cares about a specific component,
follow their lead here — phase 4 is where the real signal lives.
- Phase 5 — Logging, monitoring, edge cases (10 min, 20%). Name
the 4 golden signals per service, the failure cases (what if the
DB is down? what if a queue backs up? what if a dependency
returns 500s?), and the mitigation per case. Include a first-pass
answer on security and privacy if the system touches user data.
This phase is where amateurs run out of time; defend it.
- At the end, do a 2-minute self-summary — "here's what I built, here
are the three things I didn't solve, here's what I'd revisit".
Knowing what you didn't solve is a signal of design maturity.
- Persist all five artifacts (requirements list, API draft, data +
arch diagram, deep-dive notes, monitoring + edge cases) as a
single doc, dated and signed. This is the spec.
Rules: Do
- Enforce phase time boxes with a timer. A spec-authoring session that
drifts to "let's finalize the auth flow" in minute 40 has abandoned
the structure that makes the flow work.
- Write down assumptions the moment they are made. "Assume single
region for now" is a different design from the multi-region version
and must be tagged, not remembered.
- Let phase 1 drive phase 4. The deep-dive component selection is a
function of which NFRs bind hardest; if phase 1 was weak, phase 4
will be arbitrary.
- Use the flow for real specs, not just interviews. A 50-minute
structured session beats three 20-minute ad-hoc meetings for any
greenfield service.
- Timebox aggressively on phase 2 (API). The API shape is a scaffold,
not the deliverable; over-investing here starves phase 4.
Rules: Don't
- Don't skip phase 1 "to save time". Every skipped requirement becomes
a redesign in week three.
- Don't do deep-dive before the high-level architecture exists. You
will optimize a component that isn't needed or miss one that is.
- Don't reach phase 5 with five minutes left. That is the signal to
trim earlier phases next time, not to compress the observability
answer.
- Don't treat the flow as rigid ritual. If the problem is "design a
rate limiter", 50% of the budget on phase 4 is fine — the shape
scales to the problem.
- Don't forget to write the "what I didn't solve" list. A spec that
claims to solve everything is untrustworthy.
Expected Behavior
After this skill, any new system design session produces a five-part
artifact in roughly 50 minutes: requirements, API, data+arch,
deep-dive, and monitoring/edge cases. Time pressure stops being an
excuse for skipping observability. The team has a common vocabulary
for what "done enough for first review" means.
In interview settings, the candidate avoids the two classic failures
(all-whiteboard no-requirements, or five minutes of everything with
no depth) and lands a deep-dive phase that earns the grade.
Quality Gates
- All five phases have written output, even if short.
- Requirements include both functional and non-functional.
- Deep-dive targets the component(s) identified by NFR pressure, not
by personal interest.
- Phase 5 names failure modes, not just happy-path monitoring.
- A "what I didn't solve" list exists and is specific.
Companion Integration
Delegates phase 1's NFR half to sysdesign-nfr-clarification. Hands
phase-4 decisions to the pattern skills (sysdesign-newsfeed-fanout,
sysdesign-autocomplete-trie-fuzzy, sysdesign-top-k-count-min-sketch,
sysdesign-dual-write-event-sourcing, etc.) when applicable. Phase-5
observability delegates to sysdesign-monitoring-4-golden-signals.
When matilha core is present, this flow composes naturally with
matilha-plan in phase 20-30 (spec + plan authoring). Methodology
phase: 20-30 primarily; 10 for discovery when the design doubles as
a feasibility probe.
Output Artifacts
- A single dated spec doc with five labeled sections
(Requirements, API, Data + Architecture, Deep Dive, Monitoring +
Edge Cases).
- "Not solved" appendix listing known gaps.
- Optional: timer log showing time spent per phase (useful for
calibrating next session).
Example Constraint Language
- Use "must" for: all five phases produce written output, phase 5
receives at least 10 minutes, deep-dive targets NFR-bound components.
- Use "should" for: timeboxing with a literal timer, delegating NFR
clarification to
sysdesign-nfr-clarification, persisting the
spec dated.
- Use "may" for: scaling the flow to 25/75/100-minute sessions
proportionally, skipping phase 2 when the API is dictated (e.g.,
gRPC proto already exists).
Troubleshooting
- "We ran out of time before monitoring": phases 2-4 bloated.
Review the log; typically phase 2 (API) or a favorite subsystem in
phase 4 consumed the overflow. Next session, set harder caps.
- "The deep-dive felt arbitrary": phase 1's non-functional output
was vague. No binding NFR means no signal for which component
deserves depth. Reinvest in phase 1 next time.
- "Interviewers say I lack depth": phase 4 is underpowered.
Trade phases 2-3 for more phase 4; interviews reward depth on the
hard component, not breadth on the easy ones.
- "Real projects don't fit in 50 minutes": correct. Run the flow
multiple times per subsystem. The 50-minute shape is the unit; a
project of five subsystems is five units, scheduled separately.
Concrete Example
A team opens a 50-minute design session for a usage-metering service
that bills customers on API calls. Phase 1 (11 min) surfaces four
functional requirements (count, aggregate, expose, bill-export) and
NFR pressure on accuracy, idempotency, and 24-hour data retention
with eventual consistency on roll-ups. Phase 2 (4 min) sketches two
endpoints: POST /events and GET /aggregates/:customer/:window.
Phase 3 (9 min) picks Kafka + a time-series store for raw events,
Postgres for daily roll-ups, and a stream processor between them.
Phase 4 (17 min) deep-dives on the stream processor — exactly-once
semantics, checkpointing, late event handling, and a count-min
sketch for approximate live view (delegated to
sysdesign-top-k-count-min-sketch patterns). Phase 5 (9 min) names
monitoring (ingestion lag, processor backlog, roll-up divergence)
and failure cases (Kafka outage, processor crash, DB write
rejection). A two-minute self-summary lists three things not solved:
cross-region replication, retention-based cost bounds, and
customer-tier-specific SLOs. The spec is one page, dated, signed,
and in the repo before the hour is up.
Sources
[[concepts/nfr-system-design]] — 50-min interview flow section[[concepts/design-cases]] — pattern across all 11 cases- Synthesized from Zhiyong Tan, Acing the System Design Interview
(introductory chapters on interview methodology).
