Module F-1·20 min read

Functional vs non-functional requirements, why "it depends" is the correct answer, and how to make it specific enough to build from.

JJS

Written by Jatin Jain Saraf · Senior Software Engineer

Module F-1 — What Is System Design? Requirements, Constraints, and Trade-offs

Q: A team is asked to build "a dashboard that shows live order counts." One engineer proposes a Kafka stream feeding a materialised view; another proposes a query against the orders table every 30 seconds. According to this module, what should be established before the argument can be resolved?

The four numbers — scale and growth, read/write ratio, consistency tolerance, and availability target — plus the constraints, because both designs are correct for different values of those and the disagreement is really about unstated assumptions. — The module's central claim is that most architecture arguments are two people reasoning correctly from different unstated assumptions, and that pinning down scale, read/write ratio, consistency tolerance, and availability target collapses most of them. Here the deciding number is consistency tolerance: if 30 seconds of staleness is acceptable, the polling query is the right design and the streaming pipeline is unpaid complexity; if sub-second freshness is a real requirement, polling can't deliver it. Option A substitutes authority for requirements. Option B is exactly the "best practice without the cost named" pattern the module rejects — a Kafka cluster has an operational and financial bill that has to be justified by a requirement. Option C treats "live" as precise when it's the vaguest word in the sentence; "live" spans anything from 30 seconds to 50 milliseconds depending on who said it.

Q: A three-engineer team with an existing 800GB Postgres database, a six-week deadline, and a $2,000/month infrastructure budget is designing a new reporting feature. How does the module characterise these facts?

As constraints — hard inputs that bound the design space before any option is evaluated, so a design that ignores them is a diagram rather than an engineering plan. — The module defines constraints as "the requirements you don't get to choose" — team size, budget, deadline, existing stack and data, compliance, and physical latency floors — and argues they're design inputs rather than excuses, since a design the team cannot operate or afford will not ship no matter how well it scales. Option B is the failure mode the section is written against; a twelve-service architecture staffed by three engineers is a pager rotation, not an architecture. Option C confuses the categories: non-functional requirements are qualities *of the system* (latency, availability, durability), whereas these are properties of the environment you're building in. Option D is the split the module explicitly rejects — the migration path off an existing 800GB database, for instance, is part of the design work itself, not a scheduling detail.

Q: According to the module, what makes an architectural decision record complete?

A non-empty statement of the cost being accepted, alongside the benefits — because a decision with no named cost has been asserted rather than analysed. — The `DesignDecision` snippet makes `acceptedCost` a required, never-empty field precisely to enforce the module's stated rule: no "best practice" without its cost named. Sharding buys write scaling and costs cross-shard queries; caching buys latency and costs staleness; microservices buy independent deploys and cost you distributed failures. Option A is the incomplete half the rule exists to prevent — benefits alone are a sales pitch. Option B is useful evidence but not sufficient: winning on one metric says nothing about what the choice forecloses, which is the thing you'll actually regret. Option D records who is accountable, not what was traded away, and the module treats authority-based resolution as a substitute for analysis rather than a form of it.

What this module covers: "Design Twitter" is not a task. It's a prompt with roughly a hundred unstated decisions inside it, and the difference between a good system designer and a bad one is almost entirely about which of those decisions they surface before writing any code. This module covers what system design actually is as an activity, functional vs non-functional requirements, the four numbers that change every subsequent answer, the constraints that are handed to you rather than chosen, and why "it depends" is the correct response — plus how to make it specific enough to build from. It also establishes the rule the rest of this course follows: no recommendation without its cost named.

System Design Is Deciding What to Regret

Every system is a set of choices, and every choice closes doors. Pick Postgres and you've decided that a 500-node write cluster will be somebody's painful migration later. Pick Cassandra and you've decided that your first "show me all orders over $500 from last Tuesday, sorted by customer name" report will be a genuine engineering project rather than a five-minute query. Neither choice is wrong. Both are decisions about which future problems you'd rather have.

This is why system design interviews and system design documents both feel slippery to engineers coming from feature work. In feature work there's usually a correct answer — the button either submits the form or it doesn't. In system design there is no correct answer, only answers that are correct given a set of requirements, and the requirements are the part nobody hands you.

Analogy: System design is writing a building brief, not drawing a building. An architect who's asked to "design an office" and immediately starts drawing has skipped the only part that matters: how many people, doing what work, in what climate, on what budget, with what expansion plans over ten years. A 40-person design studio and a 40-person call centre are the same headcount and completely different buildings. "Design Twitter" is "design an office."

Why this matters in production: the most expensive engineering failures are rarely bad code. They're systems that were built correctly against requirements nobody wrote down, and then met real requirements that turned out to be different. A search feature built on LIKE '%term%' is correct code — it works, it's tested, it ships. It becomes an incident the day the table crosses a few million rows, because nobody ever asked "how many products will be in the catalogue in eighteen months, and how fast does search need to be?" The bug wasn't in the query. It was in the brief.

Functional vs Non-Functional Requirements

The single most useful split in system design is between what the system does and how well it has to do it.

Functional requirements are behaviours. A user can post a message. A user can follow another user. A user sees a timeline of posts from people they follow. These are the things a product manager writes, the things you'd demo, the things that appear in acceptance criteria. They tell you what to build.

Non-functional requirements are qualities. The timeline loads in under 300ms at the 99th percentile. The system stays available if one datacentre fails. A posted message is never lost once acknowledged. Data for EU users doesn't leave the EU. These tell you how to build it — and they are almost the entire content of system design.

Here's the thing that surprises people: the functional requirements for a timeline feature fit in a sentence and can be implemented in an afternoon. It's the non-functional requirements that generate the entire architecture.

typescript

// Functional requirement: "a user sees posts from people they follow, newest first."
// This is a complete, correct implementation.
async function getTimeline(userId: string, limit = 50) {
  return db.query(
    `SELECT p.* FROM posts p
     JOIN follows f ON f.followee_id = p.author_id
     WHERE f.follower_id = $1
     ORDER BY p.created_at DESC
     LIMIT $2`,
    [userId, limit]
  );
}

That function satisfies the functional requirement completely. It is also the version that works for 10,000 users and falls over at 10 million, because a join-and-sort across every post by everyone you follow gets more expensive as both the follow graph and the post table grow. Everything in Module A-14 — fan-out on write, the celebrity problem, precomputed timelines, cache hierarchies — exists to satisfy non-functional requirements that this query cannot: p99 under 300ms, at 100 million users, with a 60:1 read/write ratio.

The lesson to carry forward: when someone says "the design is simple," they are almost always describing the functional requirements. The design is simple. The non-functional requirements are what make it hard.

The Four Numbers That Change Every Answer

Most system design arguments are two people reasoning correctly from different unstated assumptions. You can collapse the majority of them by pinning down four numbers first.

1. Scale — how many, and how fast is it growing?

Not "a lot." A number. 10,000 users or 10 million users are different systems, and 10 million users growing 5% a month is a different system again from 10 million users flat for three years. Growth rate determines whether you design for today's load with room to react, or design the sharding scheme now because you won't get a chance to retrofit it calmly.

2. Read/write ratio — which direction is the traffic?

A social feed is read-heavy, often 100:1 or worse: every post is written once and read thousands of times. An IoT telemetry ingest is write-heavy: millions of writes, read occasionally by a dashboard. A chat system is roughly balanced. This single ratio decides whether caching is your primary tool (read-heavy — Module F-12 onward), whether you need a write-optimised storage engine (write-heavy — Module P-2), and whether read replicas will help at all (they help reads; they do nothing for a write bottleneck, as Module P-5 covers).

3. Consistency tolerance — how stale can a read be before it's a bug?

This is the question most likely to be skipped and most likely to determine the architecture. "How long after I post can my follower not see the post before someone files a ticket?" For a Twitter-like timeline, a few seconds is genuinely fine. For a bank balance after a transfer, zero seconds is fine — and note that "zero" is a much more expensive number, because it rules out the async replication that made the timeline cheap. Modules P-10 and P-11 are entirely about paying for this number honestly.

4. Availability target — what does downtime cost?

99.9% availability is about 43 minutes of downtime a month. 99.99% is about 4 minutes. That factor-of-ten difference in the number is roughly a factor-of-ten difference in cost and complexity: multi-AZ becomes multi-region, manual failover becomes automatic failover, and every deploy has to be zero-downtime rather than "quick, at 3am." Module O-2 covers how to pick this number instead of inheriting it from a slide.

Here's what those four numbers look like written down for two systems that both sound like "a feed":

	Consumer social feed	Internal ops dashboard
Scale	50M DAU, +8%/month	400 employees, flat
Read/write	~100:1 read-heavy	~20:1 read-heavy
Consistency tolerance	seconds of staleness fine	minutes of staleness fine
Availability target	99.99%	99.5%, business hours
What it implies	Precomputed timelines, multi-region, aggressive cache, sharded store	One Postgres, one cache, a nightly backup, and stop

Same functional requirement. Two completely different correct designs. The second one is not the "junior" answer — building the left-hand column for 400 employees is the far worse engineering decision, because you'd pay multi-region complexity forever to serve traffic a single server handles while idling.

Constraints: the Requirements You Don't Get to Choose

Requirements describe the goal. Constraints are the walls of the room you're building in, and pretending they don't exist is the most common way a technically excellent design fails to ship.

Budget. A design that needs nine services, a Kafka cluster, and a warehouse has a monthly bill. If the product's entire revenue is $8,000/month, a $6,000/month infrastructure design is wrong regardless of how well it scales. Module O-8 treats cost as an architectural property rather than a finance problem.
Team size and expertise. Six services per engineer is not an architecture, it's a pager rotation nobody survives. A three-person team running a monolith on managed Postgres will out-ship a three-person team running twelve microservices every single time. This is a design input, not an excuse.
Deadline. "Correct in nine months" and "adequate in six weeks" are different problems. Sometimes the right design is explicitly the one you know you'll replace, with the replacement point written down.
Existing stack and data. Greenfield is rare. You usually inherit a database with four years of data in it, three internal consumers reading it directly, and one dependency nobody can identify. The migration path is part of the design, not a follow-up ticket — see Module O-4.
Compliance and data residency. GDPR, HIPAA, PCI-DSS, India's DPDP. These arrive as hard structural constraints: this data cannot leave this region, that field cannot be logged, this record must be deletable on request even though it's currently sitting in an immutable Kafka log. Module O-9 covers the design consequences, and they are not small.
Latency floor from physics. Light in fibre covers roughly 200,000 km/s, so a Mumbai-to-Virginia round trip has a floor near 200ms no matter how good your code is. If a requirement says "sub-100ms globally," you have just been told you need multi-region infrastructure — the requirement decided it, not you.

Why this matters in production: constraints are what make a design real. A whiteboard design with no constraints is a diagram; the same design with "three engineers, $2K/month, live in eight weeks, existing 800GB Postgres" written in the corner is an engineering plan. If you take one interviewing habit from this module, make it this: ask about constraints out loud. Interviewers are listening for it, and colleagues are relieved by it.

"It Depends" Is Correct — Now Make It Specific

Engineers get mocked for answering "it depends," but it's the honest answer to almost every architecture question. The failure isn't saying it. The failure is stopping there.

An unusable answer names no dependency:

"Should we use SQL or NoSQL?" "It depends."

A useful answer names the dependency, states what each branch implies, and asks for the one fact that resolves it:

"It depends on whether your access patterns are known and stable. If you're mostly fetching by a single key — user profile by ID, cart by session — a wide-column store like DynamoDB gives you predictable single-digit-millisecond reads and horizontal scaling essentially for free. If you'll need ad-hoc queries and joins you haven't thought of yet — and any product with an admin panel or a reporting need will — Postgres gives you that for the price of harder horizontal scaling later. Which of those is closer to your next six months?"

That answer is the same "it depends," made actionable. It has three parts worth copying deliberately:

Name the axis the decision turns on ("are your access patterns known and stable?").
State the consequence of each branch, including the cost — not just what you gain.
Ask the specific question that resolves it.

This is the shape of every good system design conversation, and it's the format the rest of this course is written in.

typescript

// The habit, encoded: a decision record that forces the cost to be named.
interface DesignDecision {
  decision: string;              // "Shard orders by customer_id"
  axis: string;                  // what it turns on: "queries are per-customer"
  chosenBecause: string[];       // benefits
  acceptedCost: string[];        // REQUIRED — never empty
  revisitWhen: string;           // "any cross-customer report becomes a top-3 use case"
}

const shardingDecision: DesignDecision = {
  decision: 'Shard the orders table by customer_id',
  axis: '98% of order queries filter by a single customer',
  chosenBecause: ['single-shard reads for the hot path', 'linear write scaling'],
  acceptedCost: [
    'cross-customer analytics needs a scatter-gather or a separate warehouse',
    'a whale customer creates a hot shard (see P-6, P-8)',
    'resharding later requires a data migration, not a config change',
  ],
  revisitWhen: 'cross-customer reporting becomes a primary access pattern',
};

If acceptedCost is empty, the decision hasn't been analysed yet — it's been asserted. That's the rule this course follows: no "best practice" without its cost named. Sharding buys write scaling and costs you cross-shard queries. Caching buys latency and costs you staleness. Microservices buy independent deploys and cost you a distributed system with distributed failures. Anyone selling you one of these without the second half of the sentence is selling, not designing.

A Worked Example: Turning a Prompt Into a Brief

Take the prompt: "We need a notification system." Here's the ten-minute conversation that turns it into something buildable.

Functional scope, and explicitly what's out:

In: email and push, triggered by application events, per-user preferences, delivery status visible to support.
Out (this quarter): SMS, in-app inbox, digest batching, marketing campaigns.

Writing down what's out is half the value. It's what stops "notification system" from quietly becoming a marketing automation platform six weeks in.

The four numbers:

Scale: 2M users, ~5 notifications/user/week, so ~1.4M/day average — but event-driven, so bursty. A product launch could put 500K in five minutes, which means peak matters far more than average (Module F-3 covers exactly this trap).
Read/write: write-heavy on ingest, low read volume (support looking up a delivery).
Consistency tolerance: a notification arriving 30 seconds late is fine. A notification arriving twice is a support ticket. Duplicates are the real risk, not latency.
Availability: the notification pipeline can be down for minutes as long as nothing is lost — events must be durably queued and drain afterwards.

Constraints: two engineers, existing Postgres and Redis, no Kafka today and no appetite to run one, six weeks.

What that brief has already decided for you: the burst profile plus "nothing lost" rules out sending inline in the request path — you need a durable queue with workers (Module P-14, P-19). "Duplicates are worse than delay" makes idempotency keys a core requirement, not a nice-to-have (Module P-16). "No Kafka" plus existing Postgres and Redis says use what you have — a Postgres-backed job queue or Redis Streams — and revisit only if throughput demands it. Two engineers and six weeks says one service, not three.

Notice that no clever insight was required. The design fell out of the brief. That's the job: the reason experienced designers seem to produce architectures quickly is that they're extracting requirements quickly, and the architecture is mostly implied by the requirements once they're explicit.

Where This Shows Up in Your Stack

Next.js route handlers: the choice between rendering on the server per request, caching for a TTL, or generating statically is a non-functional decision — a staleness budget. It's the same "how stale can a read be" question as a distributed cache, just answered in a route config instead of a design doc.
PostgreSQL: picking a primary key type (Module P-3) feels like a five-second decision at schema-creation time and becomes essentially permanent. So does the partitioning key. These are the decisions worth a DesignDecision record, because the cost of getting them wrong is a migration on a table that's since grown 400GB.
Redis: reaching for a cache is a trade of staleness for latency. If nobody has stated the staleness budget out loud, you've made a product decision inside an infrastructure change, and the bug report ("I updated my profile and it still shows the old name") will arrive as a mystery rather than an expected consequence.
Serverless functions: the platform's constraints (execution ceiling, cold starts, no work after the response returns) are non-functional requirements imposed on you rather than chosen. Module F-10 is entirely about designing with them rather than discovering them at 2am.

Summary

System design is choosing which future problems to have. Every choice closes doors; the skill is closing the right ones knowingly.
Functional requirements say what the system does; non-functional requirements say how well. The functional part is usually an afternoon. The non-functional part is the architecture.
Pin down four numbers before designing: scale and growth rate, read/write ratio, consistency tolerance, availability target. Most architecture disagreements are unstated disagreements about these.
Constraints are not excuses — they're inputs. Budget, team size, deadline, existing data, compliance, and the speed of light in fibre all bound the design space before you start.
"It depends" is correct; stopping there isn't. Name the axis, state both branches with their costs, ask the question that resolves it.
No recommendation without its cost named. If a decision has no accepted cost written down, it hasn't been analysed.

The next module, Mechanical Sympathy: CPU Caches, Memory, and Disks, goes to the opposite extreme — down to the silicon. Before you can estimate anything (F-3) or understand why any storage engine is shaped the way it is (P-2), you need real numbers for how long the machine takes to do things, and one specific counterintuitive fact: a sequential disk write can beat a random memory access.

Knowledge Check

A team is asked to build "a dashboard that shows live order counts." One engineer proposes a Kafka stream feeding a materialised view; another proposes a query against the orders table every 30 seconds. According to this module, what should be established before the argument can be resolved?

A three-engineer team with an existing 800GB Postgres database, a six-week deadline, and a $2,000/month infrastructure budget is designing a new reporting feature. How does the module characterise these facts?

According to the module, what makes an architectural decision record complete?

Test your knowledge with more question sets

Sign in to keep reading

The rest of this module is free — sign in with Google to unlock it and track your progress.

Next Module F-2: Mechanical Sympathy: CPU Caches, Memory, and Disks

Discussion

Join the discussion

Loading comments...