Assessments & Drills: Choosing the Right NFR

The skill this chapter builds is picking the right non-functional requirement for a given situation and defending it. These four scenarios drill exactly that. Each has a model answer, the reasoning that produces it, and — just as important — why the tempting wrong answers are wrong.

Assessment 1: Cloud-based file store

You are leading a team developing a cloud-based file-sharing platform for a multinational corporation. The platform must have these attributes: depending on the time and need, it can handle an increasing number of requests arriving from different parts of the world; and its users have worldwide 24/7 access to its files.

From this list, state the two most important non-functional requirements: Maintainability · Scalability · Fault tolerance · Reliability · Availability

Model answer: Scalability and Availability.

The scenario states two attributes, and each maps directly to one NFR:

Why not the others:

• Fault tolerance is the mechanism you would use to achieve availability, not the requirement itself. The scenario asks what the platform must exhibit, and users experience availability — fault tolerance is how you deliver it.
• Reliability matters for any system but isn't what this scenario emphasizes. Nothing here is about correctness of operations; it's about reach and load.
• Maintainability is always valuable and is never the answer to a question phrased in terms of user-facing load and access.

Say it like this: "Scalability and availability. 'Increasing requests from different parts of the world' is scalability — specifically the size and geographical dimensions — and '24/7 worldwide access' is availability. Fault tolerance is tempting, but it's the mechanism I'd use to hit the availability target, not the requirement."

Assessment 2: Financial trading platform

A banking application supports financial transactions and online purchases. Users can view account status, transfer money, pay utility bills, and generate bank statements. From the following, identify which is most important for the system to operate effectively, then rank all three from most to least important: Low Latency · Consistency · Security

Model answer: Consistency first, then Security, then Low Latency.

The reasoning that produces the ranking: ask what failure is unrecoverable. A slow transfer is an annoyance the user forgets. A breach is a catastrophe. A wrong balance is a failure of the system's entire reason to exist — and it is the one that can silently corrupt every downstream record.

Consistency ranks first because it is the requirement that makes the system correct; security ranks second because it makes it safe; latency ranks last because it makes it pleasant.

Say it like this: "Consistency first — this system's purpose is moving money correctly, and an inconsistent balance is an unrecoverable failure of that purpose. Security second, because a breach is catastrophic but the system is at least still doing its job. Latency last: users will wait two seconds for a transfer, and I'd happily pay coordination latency to buy the other two."

Assessment 3: Spacecraft operations

A space agency operates spacecraft on missions to distant planets. Imagine a spacecraft encounters a hardware malfunction or a communication disruption with the control center on Earth. State the most important non-functional requirement whose inclusion would let us recover from this scenario, with reasoning: Reliability · Maintainability · Consistency · Fault tolerance · Availability · Scalability

Model answer: Fault tolerance.

The reasoning is driven by one constraint that dominates everything else: nobody can go fix it.

Fault tolerance is precisely the ability to continue operating even when one or more components fail. That is the literal statement of the problem. The implementation follows directly: redundant hardware, fault masking, graceful degradation to a safe mode, and checkpointing so the craft can restore a known-good state after an anomaly without needing instructions from Earth.

Why not the others:

• Reliability is close and is a reasonable second choice — but reliability is about not failing. The scenario stipulates that a failure has already happened. The question is how to survive it, which is fault tolerance.
• Availability describes being reachable, and the scenario explicitly includes a communication blackout in which the craft is not reachable and must cope anyway.
• Maintainability requires the ability to intervene, which is the one thing this scenario removes.
• Consistency and scalability are not what is at stake for a single autonomous vehicle.

Say it like this: "Fault tolerance, because the defining constraint is that no human can intervene — the hardware can't be repaired and the comms link is down. The system has to mask the fault and keep operating autonomously, which means redundancy, a safe-mode degradation path, and checkpointing so it can recover to a known-good state on its own. Reliability is a close second, but reliability is about avoiding failure, and here the failure has already occurred."

Assessment 4: Twitter live video

Consider a feature allowing users to stream live video directly within their posts. The number of users streaming live video has surged exponentially. Users are experiencing delays, and the system is struggling to handle the increased load. State the most important non-functional requirement: Reliability · Maintainability · Consistency · Fault tolerance · Availability · Scalability

Model answer: Scalability.

Read the symptoms literally: surged exponentially, struggling to handle the increased load, experiencing delays. That is the exact definition of a scalability failure — the system cannot handle increasing workload without degrading latency.

Critically, nothing is broken. No component has failed, no data is wrong, no service is unreachable. The system is doing precisely what it was built to do, at a volume it was not built for. That rules out fault tolerance, reliability, and availability, which all describe things going wrong rather than things going big.

The remedies are the scalability techniques: horizontal scaling of ingest and transcoding, CDN distribution of streams, autoscaling plus queue buffering for the burst, and sharding by stream so one popular broadcast doesn't contend with the rest.

Say it like this: "Scalability. Nothing has failed — no component is down and no data is wrong. The system is behaving correctly at a volume it wasn't provisioned for, and the delays are the symptom of that. I'd scale ingest and transcoding horizontally, push distribution to a CDN, and use queue buffering for the burst since autoscaling won't react fast enough to an exponential surge."

Rapid-fire probes

1. What's the difference between availability and reliability? · L5

Availability is the percentage of time the system accepts requests and responds — can I reach it. Reliability is the probability it performs its intended functions correctly over a period — does it do the right thing. They can invert: a data center with a severed network link has 0% instantaneous availability and 100% instantaneous reliability, because everything inside works perfectly and nobody can reach it.

2. Your service has four synchronous dependencies at 99.9% each. What's your availability? · L5

About 99.6%, because serial dependencies multiply — roughly 35 hours of downtime a year, all of it inherited. That's the argument for moving non-critical calls off the synchronous path. If I need a higher number, I either reduce the dependency count or make them redundant, since parallel redundancy multiplies unavailability instead.

3. Which is cheaper to improve, MTBF or MTTR? · Staff

Almost always MTTR. Availability is MTBF / (MTBF + MTTR), so both move the number — but doubling MTBF means eliminating half of all failures, which fights hardware and physics and hits diminishing returns. Halving MTTR means better automation, faster rollback, and clearer observability, which is under my control and usually cheaper. At scale failure is a constant background rate, so recovering in 30 seconds beats failing half as often and taking an hour.

4. What does 99.99% availability demand architecturally? · L5

52 minutes a year, about 4.4 minutes a month — less time than it takes to page a human, find the runbook, and log in. So detection and recovery must be fully automated: health-checked failover, no manual steps in the recovery path. The availability target dictates the automation, which is why maintainability work is a requirement of the SLO rather than engineering hygiene.

5. When is vertical scaling the right answer? · L5

More often than candidates admit. Modern machines are enormous, and scaling up buys months of runway in an afternoon with none of the partitioning, replication, or coordination problems. The right posture is: scale up while it's cheap, and keep the design ready to scale out — stateless services, no local session state — so the transition is available when you actually need it. Going distributed at low traffic means paying full complexity for capacity nobody's using.

6. Why doesn't adding machines give linear speedup? · Staff

Two forces. Contention — queueing on a shared resource like a single database or lock — flattens the curve, and any serialized fraction caps your maximum speedup regardless of node count. Coherency — the cost of keeping nodes in sync — actually grows with node count, so past a point throughput decreases as you add hardware. That's why the fix for a scaling wall is removing coordination, not buying more machines.

7. What makes a distributed checkpoint inconsistent? · Staff

An orphan message: one the receiver recorded as received but the sender has no record of sending. Restore that and you get a state that never existed. The mirror case — sent but not yet received — is fine, since it's just in transit and can be replayed. The rule is that a cut is consistent iff it contains no orphans, and uncoordinated checkpointing risks the domino effect, where one rollback cascades backwards through every process.

8. Three replicas at 70% utilization each. What happens when one dies? · Staff

The survivors need to absorb 105% of capacity, so they saturate, slow down, fail health checks, and get evicted — one node failure cascades into a total outage. To survive f failures out of n nodes you can only run at (n - f) / n utilization, so three nodes surviving one failure means a 66% ceiling. Redundancy you can't afford to actually use isn't redundancy.

9. Redundancy gives you 99.9999% on paper. Why don't you believe it? · Staff

Because that math assumes independent failures. Replicas in one rack share a power supply and a switch; replicas in one region share a control plane; and every replica running the same binary shares the same bug, so a bad deploy takes all of them at once. Real redundancy means spreading across failure domains and staggering deploys — otherwise you've multiplied nothing.

10. Why measure availability as success rate rather than uptime? · Staff

Because uptime misses partial failure. A node dropping 30% of requests while passing health checks is "up" on a wall clock and broken to a third of users — the gray-failure case. Success rate also weights outages by how many users were affected, so a peak-hour outage doesn't score the same as a 3 a.m. one. I'd define the SLI as client-observed success rate and set the SLO tighter than the customer-facing SLA, so we have headroom to react before we owe anyone credits.

Self-check

The cheat sheet next compresses the whole chapter into one page.