System Design Requirements Checklist Template: Scope, APIs, Scale, and Trade-Offs

Use this system design requirements checklist before drawing architecture boxes. It turns an ambiguous prompt into a small, testable contract: who uses the system, what must work, what is out of scope, which interfaces matter, what scale to support, which failures to survive, and which trade-offs you are choosing. The goal is not to ask every possible question. It is to identify the few requirements that will actually change the design.

Practice the checklist against varied PracHub interview questions, then compare your assumptions with the prompt and written guidance. A good requirements phase should make the next 35 minutes easier: the APIs follow from the user flows, the capacity estimates follow from the workload, and the architecture follows from the constraints.

The system design requirements checklist at a glance

Use seven boxes. Write one to three lines in each box before committing to an architecture.

Google describes intent-based capacity planning as encoding service needs and flexibility before generating an allocation plan. The interview version follows the same discipline: specify the requirement before selecting the implementation.

Copy-and-use system design requirements template

Fill this template while clarifying the prompt. Use MUST, SHOULD, and MAY only to communicate priority; RFC 2119 gives these words precise requirement-strength meanings in technical specifications.

SYSTEM:
USERS / ACTORS:
PRIMARY USER JOURNEY:

MUST support:
1.
2.
3.

SHOULD support:
1.
2.

OUT OF SCOPE:
1.
2.

QUALITY TARGETS:
- Latency:
- Availability:
- Durability:
- Consistency:
- Security / privacy:
- Geographic or compliance constraints:

INTERFACES:
- Command / write API:
- Query / read API:
- Async event or webhook:
- Authentication and authorization:
- Errors, idempotency, pagination, and rate limits:

SCALE ASSUMPTIONS:
- Active users:
- Average and peak requests per second:
- Read-to-write ratio:
- Average payload or object size:
- Retention period and annual storage growth:
- Concurrent connections or jobs:

FAILURE AND OPERATIONS:
- Most important failure modes:
- Timeout, retry, and backpressure policy:
- Degraded mode:
- Recovery objective:
- Metrics, logs, traces, and alerts:

TRADE-OFF LOG:
- Decision:
- Alternative considered:
- Requirement that drove the choice:
- Cost or downside accepted:
- Trigger for revisiting the decision:

If a requirement is irrelevant, say so and move on. When the interviewer does not provide a number, state a reasonable assumption and invite correction.

Scope the user journey before the feature list

Start with actors and one end-to-end journey. “Design a ticketing system” is too broad; “a buyer discovers an event, selects seats, holds inventory, pays, and receives a confirmation” creates boundaries. It reveals where correctness matters, where latency matters, and where external dependencies appear.

Separate three kinds of scope:

• Must-have flow: the path the design must complete successfully.
• Secondary flow: useful behavior you will support after the core path is credible.
• Non-goal: a plausible feature you are intentionally excluding, such as recommendations, refunds, moderation, or admin analytics.

Aim for three to five functional requirements. A longer list usually produces a shallow design. Prioritization shows that you can reduce ambiguity without pretending the prompt is fully specified.

Turn vague quality goals into measurable targets

“Fast,” “reliable,” and “scalable” are not yet requirements. Convert each relevant quality into a number, a percentile, or a clear behavior.

For latency, distinguish read from write and use a percentile when possible. For availability, identify which user flow needs the strongest target. For durability, ask what data loss is acceptable. For consistency, describe what a user must observe after a write. For recovery, separate the maximum tolerable data loss from the maximum acceptable restoration time.

Google's SRE guidance treats latency, error rate, and throughput as common service-level indicators. In an interview, two or three meaningful targets are stronger than a wall of arbitrary nines.

AWS and Google Cloud organize architecture review around security, reliability, performance, cost, operations, and sustainability. Use these as a gap check after identifying the requirements that dominate this workload.

Define APIs as contracts, not endpoint decoration

Draft the smallest interface that completes the primary flow. For each operation, record the actor, request, response, authorization rule, failure behavior, and whether retries are safe.

The OpenAPI specification models HTTP interfaces through paths, operations, parameters, requests, responses, security, and reusable schemas. That is a useful interview checklist even when you never write a formal OpenAPI document.

For each important API, ask:

• What resource or command does this operation represent?
• Who may call it, and what tenant or ownership boundary applies?
• Which identifier is client-generated versus server-generated?
• What happens when the request is repeated, arrives late, or arrives out of order?
• How are validation errors, conflicts, throttling, and unavailable dependencies represented?
• Does a list require pagination, filtering, sorting, or a stable cursor?

RFC 9110 defines idempotence as repeated identical requests having the same intended server effect as one request. State the application-level key, deduplication window, or conditional-write rule when duplicate side effects would be expensive.

Estimate only the scale that changes the design

Back-of-the-envelope math should justify decisions, not become a performance. Estimate average and peak workload, then connect the result to storage, partitioning, caching, queues, or connection management.

Use round numbers and label assumptions. A small workload may fit one primary database. Bursty traffic makes peak behavior more important than the daily average, while long-lived sockets can make concurrency more important than QPS.

Connect data, consistency, and failure requirements

Choose the data model after the access patterns are visible. List the core entities, their identifiers, the highest-volume reads and writes, and the invariants that must survive concurrency.

Then ask where state changes cross a boundary. Payments and inventory may not commit atomically; messages may be delivered twice; caches and replicas may be stale. These are requirements for deduplication, reconciliation, ordering, or user-visible status.

For each critical flow, write one failure sentence: “If dependency X is slow or unavailable, the system will do Y, the user will see Z, and recovery will occur through W.” That sentence exposes missing timeouts, retries, circuit breaking, dead-letter handling, or compensating work.

Google SRE guidance recommends capacity plans that are forward-looking and systems that behave acceptably under overload. Include admission control, backpressure, load shedding, or a degraded mode when unbounded work could turn one slow dependency into a cascading failure.

Add security, privacy, and operability before the wrap-up

Security is not a box labeled “encrypt everything.” Identify trust boundaries and protected actions.

Check authentication, authorization, tenant isolation, secrets, encryption, abuse controls, audit logs, deletion, retention, and sensitive-data exposure. A public feed and a financial ledger do not need the same depth.

For operability, name the signals that reveal user harm: request rate, error rate, latency percentiles, queue age, saturation, stale data, reconciliation backlog, or failed jobs. Include logs for diagnosis and traces when one user flow crosses multiple services. Alerts should map to an actionable condition, not merely to the existence of a component.

Keep a visible trade-off log

Strong system design answers do not hide costs. Record each major decision in four parts:

1. Requirement: what the design must optimize.
2. Options: two credible approaches.
3. Choice: the approach you recommend now.
4. Consequence: the complexity, cost, latency, consistency, or operational burden you accept.

For example: “Seat ownership must be exclusive during checkout. I would use a short-lived reservation with conditional writes rather than eventual reconciliation. This adds expiration and recovery logic, but it prevents two successful purchases for the same seat.”

Finish with a revisit trigger. A single-region database may be correct until regulation, latency, or recovery requirements change. This shows judgment without over-designing the first version.

Use the checklist in a 45-minute interview

Spend roughly five to eight minutes on requirements, but treat the timing as adjustable rather than a rule.

Minutes 0-7: confirm users, the primary journey, must-haves, non-goals, and dominant quality targets. Minutes 7-12: estimate the workload and define the minimal interfaces and data entities. Minutes 12-25: draw the high-level data flow and explain how each component satisfies a requirement.

Minutes 25-38: deep-dive into the hardest path, including concurrency, partitioning, failure, or consistency. Minutes 38-43: cover overload, observability, security, and recovery. Minutes 43-45: summarize the requirements, the main trade-off, and what you would revisit at greater scale.

If the interviewer redirects you, update the checklist before changing the architecture. A new requirement should visibly change a target, interface, data invariant, or trade-off.

Practice with PracHub system design questions

These question-bank records are practice material, not predictions of an exact interview. Each complete title in the first column links directly to its prompt and written guidance.

Run the checklist once without notes, then compare your design with the written solution. On the second attempt, keep the same prompt but change one requirement, such as regional availability, retention, or consistency. The value is learning which architecture decisions should move when the requirements move.

Frequently asked questions

What is the difference between functional and non-functional requirements?

Functional requirements describe user-visible capabilities, such as creating a short URL or sending a message. Non-functional requirements describe qualities and constraints, such as latency, availability, consistency, durability, privacy, scale, and cost. The architecture should connect both: a feature without a quality target is underspecified, while a quality target without a user flow lacks context.

How many requirements should I clarify in a system design interview?

Three to five must-have functions plus the two or three quality constraints that most affect the design are usually enough to begin. Add detail during the deep dive.

Should API design come before the data model?

Start with the user flow, then sketch the external contract and core entities together. The API reveals operations and ownership boundaries; the data model reveals invariants and access patterns. Iterate between them rather than treating either as permanently first.

How precise should capacity estimates be?

Use one significant digit unless the prompt supplies precise data. Show units, separate average from peak, and explain which decision the estimate affects. An explicit assumption that drives a sound choice is more useful than precise arithmetic built on an unsupported number.

What should I do when the interviewer changes a requirement?

Restate the change, update the relevant checklist field, and identify which parts of the design are affected. Preserve components that still satisfy the contract. This demonstrates adaptability and keeps the conversation traceable instead of redrawing the system from scratch.

Final takeaway: the checklist is successful when every major box in the architecture has a requirement behind it. Clarify the user journey, prioritize a small feature set, quantify the qualities that matter, define minimal contracts, estimate the workload, plan for failure, and state the trade-offs openly. Then rehearse the structure across different PracHub prompts until it feels natural under time pressure.

Sources and Further Reading

• AWS Well-Architected Framework: The Pillars of the Framework
• Google Cloud Well-Architected Framework
• Google SRE Book: Service Level Objectives
• Google SRE Book: Software Engineering in SRE and Intent-Based Capacity Planning
• Google SRE Book: Addressing Cascading Failures
• OpenAPI Specification
• RFC 9110: HTTP Semantics
• RFC 2119: Requirement Level Keywords

Research note: Technical references and PracHub destinations were checked on August 28, 2026. Interview prompts vary, so adapt the checklist to the scope and signals provided by your interviewer.