NALSD — Non-Abstract Large System Design

The SRE Workbook's structured approach to system design interviews: requirements quantification, component sizing, and explicit trade-off documentation.

Overview

Non-abstract means real numbers

SRE Workbook Chapter 12 introduces Non-Abstract Large System Design (NALSD), a structured method for designing production systems that SREs must operate. "Non-abstract" is load-bearing: unlike whiteboard designs that wave at "a database" or "a cache," NALSD requires concrete numbers at every step.

Actual QPS, actual storage bytes, actual machine counts, actual failure domains.

> [!IMPORTANT] "A distributed system that requires 10,000 machines to handle a 1,000 QPS workload is not a good design, even if it is functionally correct." A review that skips capacity estimation cannot judge operational feasibility.

The five phases

1. Clarify requirements — Functional (what the system must do) and non-functional (scale, latency targets, availability SLO, geographic distribution)
2. Estimate capacity — Derive steady-state load from first principles, plus storage growth per day
3. Design components — Which components, how they communicate, where state lives
4. Analyze reliability — Single points of failure, failure domains, and whether the design meets the SLO under realistic failures
5. Document trade-offs — What you sacrificed to get the design's strengths

Capacity from first principles

Users — 10M DAU
Requests per user per day — 50
Steady-state load — ~5,000 QPS
Peak load, 3x factor — ~15,000 QPS

Key concepts

NALSD: Non-Abstract Large System Design. A structured method requiring concrete numbers (QPS, storage, machine counts) at each design phase, not abstract component names.
Requirements phase: Establish functional requirements (what must it do) and non-functional requirements (scale, latency SLO, availability SLO, geographic constraints) before designing anything.
Capacity estimation: Derive steady-state QPS, storage growth rate, and bandwidth from first principles (DAU × requests/day, record size × write rate). The most-skipped and most-important design step.
Failure domain analysis: For each component, identify the blast radius of its failure: what breaks, how many users are affected, and whether the stated SLO can still be met.
Trade-off documentation: Every design choice has a cost. NALSD requires naming what you gave up: latency for throughput, consistency for availability, cost for redundancy.

When to use it

System design interviews — the NALSD framework gives a structured answer to "design X at Google scale"
Production readiness reviews — the reliability analysis phase exposes SPOFs before launch
Capacity planning for a new service — requirements → estimate → component → sizing
"Walk me through how you would design this system" — NALSD provides the five-phase structure

Interview questions

Walk through the NALSD method for designing a URL shortener serving 100M users.