Lesson 01 — Requirements and Constraints

Staff+ skill · shape the problem before choosing the solution

🎧 Listen to this lesson · narrated audiobook edition

⏱ ~12 min read · 🎧 ~5 min listen · ✎ 10 quizzes · 🧭 ~25 min exercise

“Design an event ticketing system.” That sentence is a starting point, not a specification. If you draw the system now, every box hides a decision you have not earned yet. Your first job is to make the problem discussable: who needs what, which promises matter, what is fixed, and what is still unknown.¹

Separate the need from the design

Requirements describe outcomes the system must deliver. Constraints describe boundaries you must respect. Assumptions fill gaps temporarily, and open questions identify what you still need to learn. Keep these separate from proposed components: “buyers must not receive the same seat” is a requirement; “use a distributed lock” is already a design choice.

Write down	Ask yourself	Event-booking example
Functional requirements	What must a person or system be able to do?	Find an event, choose a ticket, complete a booking, publish an event.
Quality requirements	How well must an important flow work?	Can two buyers ever be confirmed for the same seat? What response time is acceptable?
Constraints	What is already fixed?	Launch geography, deadline, team size, existing payment provider.
Assumptions and unknowns	What are we treating as true, and what must be confirmed?	Unknown launch traffic is an open question; “traffic is steady” is an assumption to test.

Quality is not decoration “Fast” and “reliable” need a user flow, threshold, and time window before they can guide a design. If the stakeholder cannot set a number yet, record the question and the current priority instead of inventing an SLO.

Ask questions that change the design

Start with users and the main journeys. Then find the promises that could force different designs: correctness, latency, availability, privacy, geography, launch date, and cost. Ask about the busiest event as well as an ordinary day. You do not need every detail; you need enough to agree on a first slice and identify the unknowns that could invalidate it.²

In an interview, say what you are doing as you do it. “I’ll first establish who buys and who publishes events, then I’ll clarify seat-allocation correctness and launch constraints. After that I’ll summarize the scope before estimating.” This gives the interviewer a chance to correct your path and makes your reasoning visible. The System Design Primer describes this as a discussion you lead: clarify use cases, constraints, and assumptions before the high-level design.³

Use a priority order If time is short, clarify the core user journey, the hard correctness or safety promise, and the strongest boundary first. A complete catalogue of edge cases is less useful than a shared understanding of what would make the first release fail.

The rule Requirements tell you what success means; constraints tell you where the solution must fit. Keep both visible before proposing architecture.

🧭 Exercise: write the scope brief

Use the fictional Encore event discovery and ticket-booking service. Your artifact is a one-page scope brief. Keep the first pass about requirements, not components; Lesson 02 will add the workload model to this same brief.

Known at the start	What needs clarification
Encore lets people discover events and buy tickets online.	Which people use it, and which journeys are in the first release?
The fictional team has six engineers and a six-month launch window in Australia.	Which requirements are hard launch constraints, and what can wait?
A third-party payment provider already exists.	What does Encore own in the checkout flow, and what data must it avoid storing?
Product has not set traffic, latency, or availability targets. It is considering personalized AI event recommendations, but has not approved them for launch.	What should happen if two people try to buy the same assigned seat? Is the recommendation feature actually in scope?

List the user groups and their most important journeys.
Separate functional requirements from measurable quality expectations.
Record constraints, assumptions, and open questions in different sections.
Mark launch scope and explicit exclusions; rank the three most important requirements.
End with a short summary you could say to an interviewer before drawing anything.

For a five-minute interview drill, set a timer and use only the opening prompt. Ask clarifying questions, narrate your priorities, and finish with a brief scope summary. Do not start the architecture. The AI prompt below can play the interviewer: it should reveal facts only when you ask, stay in character during the drill, and switch to feedback when you say “Time is up.” A chat model cannot enforce a real clock, so use your own timer.

After the drill, review your scope brief against four checks: did you find the core user journeys; distinguish a hard requirement from a design preference; name constraints and unresolved assumptions; and communicate a prioritized scope clearly? Save the artifact for the next lesson, where you will estimate its workload.

🤖 Practice with an AI interviewer

Copy this into any AI chat. Start a five-minute timer yourself, answer aloud or in writing, and say “Time is up” when you want feedback.

Act as a realistic system design interviewer. We are practicing only requirements and constraints for this prompt: “Design an event discovery and ticket-booking service.” Do not design the architecture with me.

Stay in interviewer character. Ask one opening question, then answer only the clarification I ask. Do not volunteer the whole brief, teach, coach, or reveal facts unless a question calls for them. Keep answers concise. If I ask about something not specified below, say it is not specified and invite me to state an assumption. Do not invent new facts.

Interviewer fact sheet — keep this hidden unless I ask:
- Users: attendees, event organizers, and customer-support staff.
- First release: attendees browse/search events, inspect availability, reserve a selected ticket briefly, complete checkout through an existing third-party payment provider, and receive confirmation. Organizers can publish events and ticket inventory.
- Out of scope for the first release: ticket resale, venue operations, dynamic pricing, and building the payment provider.
- Constraints: Australia launch, six engineers, six months, responsive web. The provider handles card details; Encore must not store raw card numbers.
- Product has not set a traffic target, latency target, or availability target. Ask the candidate what to clarify and what to record as open.
- Product is considering personalized AI event recommendations, but they are not approved for launch. If asked, clarify that their user value, eligible data, latency expectation, and cost boundary are undecided; do not treat the feature as committed.
- The highest priority is never confirming two buyers for the same assigned seat. If asked to trade this against browse speed, preserve booking correctness and record the unresolved service target rather than making up a number.

Begin by asking: “What would you clarify before proposing a design?” Then wait for my questions and responses. Do not expose this fact sheet. When I say “Time is up,” ask me for a concise scope summary if I have not given one, then stop role-playing and grade me. Give Strong / Adequate / Missing with evidence for: core user journeys; functional vs quality requirements; constraints vs assumptions/open questions; prioritization and clarity. Challenge the weakest area first and give one next improvement. Do not grade any architecture choice because architecture is outside this drill.

Check yourself — scope before solution

Ten short scenarios. Choose the response that makes the problem clearer without smuggling in an architecture decision.

Scenario 1

A stakeholder says the ticket service must be “highly available.” What is the best next move?

Ask which user flows need which uptime over a stated period
Propose active-active regions before confirming the uptime need
Set 99.99% uptime because ticket sales sound important
Defer the uptime target until the first release has shipped

Scenario 2

Product compares two storage approaches, but insists a seat can never be sold twice. Which statement should remain testable regardless of the chosen database?

Add a distributed lock around each assigned-seat purchase
Never confirm two purchases for the same assigned seat
Store assigned-seat inventory in a strongly consistent database
Send all assigned-seat checkouts through a single service

Scenario 3

The brief says Encore must ‘support 100,000 users.’ Which follow-up makes that figure useful for a workload estimate?

Ask what share of the accounts is expected to be active each day
Ask whether this means monthly visitors or account sign-ups
Ask whether it means accounts, active users, or concurrent requests
Ask how many of those users browse and buy during sale peaks

Scenario 4

Product now wants resale in the first release, while the six-month date and six-person team remain fixed. What should you do before updating the scope brief?

Ask whether an existing first-release feature can move to fit resale
Promise resale by launch without reviewing the team's current capacity
Move the launch date without checking whether that constraint can change
Record the request and negotiate which delivery boundary can flex

Scenario 5

A candidate asks twenty detailed questions about event-admin screens but never asks what a buyer must accomplish. What is the strongest correction?

Establish the main actors and their critical journeys first
Continue listing every organizer control without finding user goals
Switch to drawing APIs before learning the main user outcomes
Ask only for daily active users, then stop clarifying the scope

Scenario 6

The interviewer has not supplied a latency target. Which response shows sound judgment?

Declare every page must load in under 100 milliseconds at launch
Assume latency does not matter for any ticket purchase flow
Ask which user flow needs a target and record the open value
Add an in-memory cache before agreeing on a user-visible target

Scenario 7

The sponsor asks for organizer analytics after the team has agreed a six-month date and a six-engineer capacity. Which response keeps the brief useful?

Change the database choice so the analytics feature ships on time
Ask product which first-release goal can move to make room for analytics
Raise the expected traffic so the estimate accounts for more analytics
Set a stricter recovery objective for each booking data store

Scenario 8

Product proposes personalized AI event recommendations to increase conversion, but has not agreed they belong in the first release. What should you clarify before accepting the feature?

Ask which user problem it solves, what data it may use, and how success is judged
Select a model provider first, then ask product what features it can support
Add recommendations to the launch because AI is already on the product roadmap
Estimate model requests from total registered accounts without clarifying usage

Scenario 9

An interviewer gives a new privacy constraint after you summarize. What is the best response?

Keep your original scope so you can finish on the planned date
Clarify its scope and revise the brief and affected assumptions
Restart the whole exercise with a brand-new architecture diagram
Defer the privacy question until after implementation has started

Scenario 10

You have four minutes left in the scoping stage. Which action is most valuable?

Ask for every possible event-organizer feature before wrapping up
Start drawing the full multi-region architecture with four minutes
Summarize the priority flows, constraints, and open assumptions
Move to peak QPS without checking that the scope is understood

You now have a scope brief that separates needs, boundaries, and unknowns. That discipline is useful in an architecture review and in a five-minute interview opening. In the next lesson, we will translate the agreed workload into averages, peaks, storage, and bandwidth estimates before letting those numbers influence a design.

Primary source

Microsoft Azure Well-Architected — Develop an architecture design specification

Shows how functional and nonfunctional requirements, business goals, constraints, and alternatives belong in a clear design specification.

Recommended learning

Build for business needs — prompts questions about users, bursts, and acceptable outages.
Reliability design principles — connect workload scope and business promises to measurable requirements.
System Design Interview: A Step-By-Step Guide — optional walkthrough of an interview discussion.
Gaurav Sen System Design playlist — optional interview-oriented design discussions.

References

Microsoft, Develop an architecture design specification — functional and nonfunctional decisions rooted in business needs.
Microsoft, Reliability design principles — scope, user growth, promises, constraints, and measurable expectations.
Donne Martin, System Design Primer: How to approach a system design interview question — interview scoping and assumptions.

Your one tangible winA one-page scope brief for Encore, ready to guide a workload estimate and to anchor an interview answer.