Most system design prep teaches you to draw the right boxes. NALSD — Non-Abstract Large System Design — is the interview format that refuses to accept boxes. Formalized by Google's Site Reliability Engineering organization and documented publicly in the Google SRE Workbook, it demands that every design be iterated into concrete numbers: how many machines, how much disk, how many queries per second per replica — until the arithmetic proves the system works, or proves it doesn't.
NALSD-style rounds are a standard part of Google SRE and infrastructure interview loops, and the style is spreading: senior system design interviewers at many companies now push past the diagram with "how many machines is that?", whether or not they use the acronym. Very little prep material covers the format directly, which makes it one of the highest-leverage things a senior candidate can practice. This guide explains the method, walks a full example the non-abstract way, and shows how to train for it.
What NALSD Actually Is
NALSD is a design methodology before it is an interview format. The name is the thesis: a large system design that is still abstract — boxes labeled "database", "queue", "load balancer" with no capacities attached — is not yet a design. It is a sketch of one. The non-abstract discipline forces every component to answer for itself in numbers:
- A "database" becomes: this many rows of this size, so this much storage, requiring this many nodes at this much disk each, serving this many reads per second per replica.
- A "queue" becomes: this ingest rate against this per-partition throughput, so this many partitions, with this much retention buffer when consumers stall.
- A "load balancer" becomes: this much aggregate bandwidth, which does or does not fit through one machine's network interface.
The point is not precision — every input is an estimate. The point is that the shape of the design is dictated by arithmetic instead of intuition. Sharding, caching, and replication stop being decorations you add to look thorough and become conclusions the numbers force (or forbid — cutting an unnecessary component scores just as well).
If you want the one-paragraph reference version, the NALSD entry in our Interview Concepts library covers the definition and interview angle; the rest of this post is the practitioner's version.
The NALSD Iteration Ladder
The SRE Workbook describes NALSD as iterative refinement through a fixed sequence of questions. Interviewers walk the same ladder:
- Is it possible? Design the system with no scale pressure at all — one machine, one database. Get the data model and the core flow right.
- Can we do better? Refine the basic design: remove redundant work, tighten the data path, question every component's necessity.
- Is it feasible at scale? Now apply the real numbers. Compute the QPS, storage, and bandwidth; divide by per-machine limits; get machine counts. This is where the single-machine design shatters and the distributed design is derived, not assumed.
- Is it resilient? Kill a machine, a rack, a datacenter — on paper. What breaks? What is the blast radius? What does N+2 capacity cost?
- Can we do better — again? With the full-scale, failure-tolerant design visible, iterate once more against cost and operational load.
The ladder is why NALSD rounds feel different from standard loops: the interviewer is not waiting for a finished architecture, they are watching how the design changes when a calculation contradicts it. Revising your own design out loud is scored as strength, not backtracking.
NALSD vs the Standard System Design Round
| Standard system design round | NALSD-style round | |
|---|---|---|
| Deliverable | A coherent architecture with justified tradeoffs | An architecture plus the arithmetic proving it works at the stated scale |
| Estimation | One capacity-estimation segment, often skippable | Continuous — every component gets numbers, repeatedly |
| What kills you | Missing components, poor tradeoff reasoning | Designs that contradict their own math; unit errors; hand-waving past per-machine limits |
| Vocabulary | "We'd shard the database and add a cache" | "That's 40 TB and 300K reads/sec — at 10K reads/sec per node that's 30 replicas minimum, so we shard by user_id across 40 nodes for headroom" |
| Common at | General SWE loops at FAANG (Facebook/Meta, Apple, Amazon, Netflix, Google) and AI-first companies | Google SRE and infrastructure loops; senior/staff loops increasingly everywhere |
The formats are complementary, not competing: the clarifying-questions discipline of a standard round still opens a NALSD round — you cannot compute anything until you have pinned down the load.
Worked Example: Log Ingestion, the Non-Abstract Way
A classic NALSD-flavored prompt: "Design a system that collects logs from all of our production machines and makes them searchable." Here is the ladder applied, with the arithmetic shown the way an interviewer wants to hear it.
Pin the load first. Say the fleet is 1 million hosts, each emitting an average of 10 KB/s of logs. That is 1M × 10 KB/s = 10 GB/s of ingest. Per day: 10 GB/s × 86,400 s ≈ 860 TB/day — call it about a petabyte a day. Thirty-day retention is ~26 PB raw, ~78 PB at 3x replication. Two sentences in, the numbers have already made the big decisions: this is a horizontally sharded, append-only pipeline into blob-style storage, and nothing else was ever on the table.
Is one of anything possible? No — prove it. A disk sustains roughly 100–200 MB/s of sequential writes. At 10 GB/s of ingest, that is at least 50–100 disks writing in parallel before replication — 150–300 disks with 3x replication — so the ingest tier is a partitioned log (Kafka-shaped) from the start. A distributed message queue is the derived answer here, and the partition count is not a vibe: at ~100 MB/s per partition leader, 10 GB/s needs ~100 partitions minimum, so provision 200–300 for headroom and hot-spot tolerance.
Can we do better? 10 KB/s per host is mostly redundant text. Batch and compress at the agent: logs compress 5–10x, so shipping compressed batches cuts ingest to 1–2 GB/s and the network/disk math by the same factor. One design decision, driven entirely by a number, just deleted two-thirds of the fleet cost. (This is the NALSD move interviewers remember.)
Is it resilient? Kill a rack of ingest brokers: partitions re-elect leaders onto surviving replicas — which is why replication was ×3 in the storage math from the beginning, not an afterthought. Kill a datacenter: either logs buffer at the agents (bounded by agent disk — compute it: 10 KB/s × 3,600 s = 36 MB/hour per host, so hours of buffer are nearly free) or the pipeline runs active-active across regions at double the storage cost. Saying which and why — with the buffer arithmetic — is the resilience answer.
Notice what never happened: we never argued about technologies. The numbers chose the architecture, which is precisely the skill the round exists to test. Our back-of-the-envelope guide covers the estimation toolkit this example leans on — the ÷86,400 shortcut, the unit ladder, compression and replication factors.
The Numbers You Need Cold
NALSD arithmetic is only fast if the per-machine constants are memorized. The working set is small:
The classic latency table (memory reference vs SSD vs disk seek vs cross-region round trip) is the other half of the toolkit — our free latency numbers reference presents it on a log scale with interview usage patterns, and the back-of-the-envelope calculator lets you drill the QPS/storage/bandwidth conversions until they are automatic.
How to Practice NALSD
Reading about NALSD has the same limitation as reading any system design solution: the round tests production of arithmetic under pressure, not recognition of it. Three drills that transfer directly:
- Re-derive machine counts for designs you already know. Take a design you have studied — a URL shortener, a key-value store, a news feed — and force it non-abstract: how many nodes, what disk, what QPS per replica, what breaks first as load doubles. TierOnePrep's interactive system design questions are built for exactly this — every guide's Design phase includes capacity calculations with real numbers as a first-class step, modeled on real interview patterns at Google and other infrastructure-heavy companies.
- Drill the conversions until they are reflexive. Daily volume ÷ ~100K = QPS; users × payload = storage; the calculator exists so you can push numbers through the formulas repeatedly and check yourself.
- Practice the resilience pass out loud. For any design, narrate the death of a machine, a rack, and a region — with the capacity math for what remains. N+2 provisioning ("survive one planned and one unplanned outage") is the vocabulary interviewers use.
For Google specifically, the Google prep page covers how their loops weight design depth; SRE candidates should expect the NALSD flavor explicitly.
If you would rather follow a sequence than pick drills, the six-week SRE study plan opens with this article and orders the questions above, easiest first, with capacity estimation as its own week.
FAQ
What does NALSD stand for?
Non-Abstract Large System Design. The term comes from Google's Site Reliability Engineering organization and is documented in the Google SRE Workbook (chapter 12). You will also see it written "non-abstract large-scale system design" informally — same concept: designs must be iterated into concrete numbers (machines, disks, QPS) rather than left as abstract block diagrams.
Which companies ask NALSD interview questions?
Google is the origin and the most explicit — NALSD-style rounds are standard in Google SRE and infrastructure engineering loops. The numbers-first style, without the acronym, increasingly appears in senior and staff system design interviews at other infrastructure-heavy companies: interviewers push any design toward machine counts and per-node limits to separate candidates who have operated systems from those who have only diagrammed them.
How is NALSD different from a normal system design interview?
A standard round evaluates architecture and tradeoff reasoning, with estimation as one segment. A NALSD round makes the arithmetic the spine of the whole conversation: every component must be justified by throughput, storage, and machine-count numbers, the design is iterated when calculations contradict it, and a resilience pass (machine, rack, datacenter failure) is computed rather than asserted.
How do I practice for a NALSD interview?
Train the two component skills separately, then combine them. First, make estimation reflexive: QPS, storage, bandwidth, and cache conversions, plus the per-machine constants (disk throughput, node QPS, NIC bandwidth). Second, practice iterating real designs into numbers — take questions you know, compute the machine counts, double the load, and find what breaks. TierOnePrep's interactive questions include capacity calculations in every system design guide, and the free back-of-envelope calculator and latency reference drill the conversions.
Is NALSD only relevant for SRE roles?
No. It originated in SRE hiring, but the underlying skill — proving a design works with arithmetic — is exactly what separates senior from mid-level performance in any system design round. Even in loops that never say "NALSD", the follow-ups ("what's the QPS per node?", "does that fit in RAM?") are the same questions, and candidates who answer them with numbers stand out immediately.