Requirements

Two BoxOffice engineers receive the same request from the product team: "We need a ticketing platform that is fast, scalable and reliable." The first one starts drawing boxes. The second one asks: How many events per month? How many fans at the peak of an on-sale? What does "fast" mean — for browsing or for paying? Can we ever sell the same seat twice? What happens if the payment provider is down? Three months later the first engineer has a beautiful architecture for the wrong problem. The second has a less impressive diagram that survives 10:00 on Friday.

Requirements are the input of every design. A design can only be judged against them: "is this a good architecture?" is unanswerable; "does this architecture keep checkout p99 under 1.5 s with 60,000 seats and 2 million fans, without double booking, for less than R$ 40k per month?" is a question you can test.

Two kinds of requirements

Functional requirements decide which APIs and data exist. Non-functional requirements decide which architecture delivers them. In system design, the non-functional side drives almost every decision: the same "sell a ticket" feature can be a single PostgreSQL table for a theatre with 200 seats, or a waiting room, a sharded inventory and an event stream for a stadium.

Functional requirements

Start from actors (who uses the system) and their goals. For BoxOffice:

Then turn the goals into a short, prioritized list. In practice — and in an interview — you cannot design everything, so you pick the core path and say explicitly what is out of scope:

A good way to check that a functional requirement is complete is to sketch its API. If you cannot write the request and the response, the requirement is still vague:

GET  /events?city=sao-paulo&from=2027-03-01&q=rock      → 200 [ {eventId, name, venue, date, minPrice} ]
GET  /events/{eventId}/seats                            → 200 { sections: [...], available: [...] }
POST /events/{eventId}/holds   { seatIds: [...] }       → 201 { holdId, expiresAt }   | 409 seat taken
POST /orders                   { holdId, paymentToken } → 201 { orderId, status }     | 402 declined
GET  /orders/{orderId}                                  → 200 { status, tickets: [...] }

You will detail APIs and data models in class 5 and class 6; at this stage the goal is only to make the scope concrete.

Non-functional requirements: the quality attributes

Non-functional requirements describe qualities of the system. Software architecture literature calls them quality attributes¹ (ISO/IEC 25010 standardizes a long list of them²). For system design, eight carry most of the weight:

The rest of this section gives each attribute a precise meaning — "scalable" and "available" are used loosely in everyday speech, and loose words make bad requirements.

Scalability

Scalability is the ability to handle more load by adding resources, keeping performance acceptable. It is not a yes/no property: "is it scalable?" is meaningless until you say which load parameter grows and by how much³. For BoxOffice the load parameters differ per part of the system:

• catalog: page views per second (read-heavy, highly cacheable);
• inventory: seat holds per second on a single event (write-heavy, all on the same hot rows);
• notification: e-mails per minute after an on-sale (bursty, can be delayed).

Each one scales with a different technique: caching and CDN for the first, partitioning and a waiting room for the second, a queue and workers for the third. Two directions exist, and you will use both:

• Vertical scaling (scale up): a bigger machine. Simple, no code change, but limited by the largest machine you can buy and still a single point of failure.
• Horizontal scaling (scale out): more machines. Practically unlimited for stateless components, but requires a load balancer, stateless servers, and — for data — partitioning and replication.

Availability

Availability is the fraction of time (or of requests) in which the system serves users correctly. It is quoted in "nines" and always over a window: 99.9% per rolling 28 days allows about 40 minutes of downtime; 99.99% allows about 4 minutes. Each extra nine costs much more than the previous one — class 2 gives you the math, and class 10 the engineering.

Availability is not uniform either: BoxOffice can live with the recommendation widget down for an hour, but not with checkout down during an on-sale.

Latency (and throughput)

Latency (response time) is how long a request takes, as seen by the client. Throughput is how many requests per second the system completes. They are linked — near saturation, latency explodes (class 2) — so a latency target is only meaningful at a given throughput.

Always state latency as a percentile, not an average: "p99 < 300 ms" means 99% of requests finish in under 300 ms. Averages hide the slow requests that users remember (percentiles and tail latency). Classic usability research gives useful anchors for user-facing targets: about 0.1 s feels instantaneous, about 1 s keeps the user's flow of thought, and beyond about 10 s users lose attention⁴.

Consistency

Consistency (in the system-design sense) is about what readers see after a write. With strong consistency, once a write is acknowledged every subsequent read sees it — the system behaves as if there were a single copy of the data. With eventual consistency, replicas may disagree for a while, but converge if writes stop.

The key insight is that not all data needs the same consistency:

Strong consistency costs latency and availability (you will see why with CAP and PACELC in class 3), so you pay for it only where the business needs it.

Durability

Durability means that data, once confirmed, is not lost — even if disks, machines or a whole data centre fail. It is achieved with replication (several copies, ideally in different failure domains), write-ahead logs, backups and tested restores. Its requirement is usually expressed as an RPO (Recovery Point Objective — how much recent data you may lose in a disaster): for BoxOffice orders, RPO = 0; for analytics events, a few minutes is acceptable.

Do not confuse durability with availability: a database can be down (unavailable) without losing anything (durable), and vice-versa a cache can be up while keeping nothing durable.

Cost

Every component has a price: machines, managed services, storage, network egress, third-party fees, and the people to operate it. Cost is a first-class requirement — an architecture that meets every other target at ten times the budget is a failed architecture. Good cost requirements are tied to the business: cost per ticket sold, cost per active user, or a monthly ceiling. Note also that BoxOffice traffic is spiky: paying all month for the capacity of a 10-minute on-sale is wasteful, which is why autoscaling, queues and serverless matter (class 11 covers FinOps).

Security

Security protects confidentiality (only the right people read data), integrity (only the right people change it) and availability (attackers cannot take it down) — the CIA triad. For BoxOffice it translates into concrete requirements: fans authenticate before buying; an organizer only sees their own events; bots cannot buy 500 tickets in one second; card numbers never touch BoxOffice servers (the payment provider tokenizes them, which keeps BoxOffice out of most of the PCI DSS scope⁵); personal data follows Brazil's data-protection law, the LGPD (Lei Geral de Proteção de Dados)⁶.

Operability

Operability groups the qualities that make a system runnable by real people: observability (can we tell what is wrong?), deployability (can we ship a change safely, many times a day?), maintainability (can a new engineer understand and change it?), and recoverability (how fast do we restore service — the MTTR, Mean Time To Recovery). It is the attribute most often forgotten in diagrams and most often blamed in post-mortems.

Making non-functional requirements measurable

"The system must be fast" cannot be tested, so it cannot be designed for. A practical template from software architecture is the quality attribute scenario¹, which forces six parts into one sentence:

flowchart LR
    source["Source<br/>who/what"] --> stimulus["Stimulus<br/>what happens"]
    stimulus --> artifact["Artifact<br/>which part, in which<br/>environment"]
    artifact --> response["Response<br/>what the system does"]
    response --> measure["Response measure<br/>the number"]

Written as requirements, a measurable set for BoxOffice looks like this:

Each line is testable — with a load test, a chaos experiment or a monthly bill — and each line will drive a design decision in the coming classes.

export const options = {
  vus: 1,
  duration: '30s',
  summaryTrendStats: ['avg', 'med', 'p(95)', 'p(99)', 'max'],
  thresholds: {
    http_req_failed: ['rate==0'],
    // one threshold per endpoint makes k6 print one latency line per endpoint
    'http_req_duration{name:GET /catalog/events/{id}}': ['p(95)<200'],
    'http_req_duration{name:GET /catalog/events?city}': ['p(95)<500'],
  },
};

Trade-offs between quality attributes

Quality attributes pull against each other. Recognizing the tension before choosing a component is the essence of system design:

This is why the same company runs different architectures for different parts of the same product. BoxOffice's catalog is an AP-leaning, cache-everything system; its inventory is a CP-leaning, transaction-everything system; its notifications are an asynchronous, retry-until-delivered system.

Constraints and assumptions

Requirements come with constraints — decisions already made for you — and assumptions — things you take as true to move on:

• Team and skills: a team of six that knows Java and PostgreSQL should not adopt five new databases.
• Time: "on-sale in 8 weeks" rules out rewriting everything as microservices.
• Budget: a monthly ceiling, or a cost-per-ticket target.
• Regulation: LGPD for personal data; PCI DSS for payments; tax rules for invoices.
• Existing systems: the payment provider's API and its rate limits; the organizer's ERP.
• Assumptions: "fans per on-sale follow last year's distribution", "the provider answers in 300–800 ms". Write them down — when an assumption is wrong, you know which part of the design to revisit.

How it connects

flowchart LR
    FR["functional requirements<br/>actors, core path"] --> API["API & data model<br/>→ Compute, Databases"]
    NFR["quality attributes"] --> QAS["quality attribute scenario<br/>a measurable target"]
    QAS --> EST["load numbers<br/>→ Estimation"]
    NFR --> SC["scalability<br/>lb, cache, queue"]
    NFR --> LAT["latency percentiles<br/>→ Estimation"]
    NFR --> AV["availability nines<br/>→ Reliability"]
    NFR --> CO["consistency per data item<br/>→ Distributed systems"]
    NFR --> SEC["security<br/>→ Network & Security"]
    NFR --> OPS["operability<br/>→ Observability"]
    CO --> TO["trade-offs: CP inventory,<br/>AP catalog"]
    LAT --> TO

Palette components: client · mobile (the actors' entry points) · sql (strong consistency for seats, durability of orders) · cache · cdn (latency bought with freshness) · lb (scalability and availability through replicas) · waf · auth (security) · payment (an external constraint: no card data stored) · metrics (operability). Scenarios: monolith, flash-sale. Continues in: Estimation — numbers, Estimation — percentiles, Estimation — availability math, Distributed — CAP and PACELC, Observability — SLOs, Exercise: design doc.

Key takeaways