How to pass the Google SRE NALSD interview

Standard system design interviews usually let you draw a few boxes labeled Database and Cache before calling it a day. The Google Site Reliability Engineering (SRE) Non-Abstract Large System Design (NALSD) interview definitely doesn't. In a NALSD round, you actually have to prove those boxes work within the strict physical constraints of real hardware, networking, and physics. You aren't just playing architect here—you're stepping into the role of a capacity planner. If you draw a line between two boxes, the interviewer will ask: What is the bandwidth of that link? What happens when the switch connecting them loses power?

Why NALSD is different from standard system design

A typical software engineering system design interview focuses heavily on abstract architecture, API design, and data models. NALSD flips that script entirely. You are expected to design a system, but then you must translate that high-level architecture into a concrete Bill of Materials (BOM). That means calculating exactly how many servers, disks, and network switches you'll need to handle the load, factoring in failure domains and necessary redundancy. You cannot simply say you will autoscale. You must say, We need 45 machines, each with 64GB of RAM and 2TB NVMe SSDs, distributed across three independent power domains to survive a datacenter floor outage.

Adopting a physics-first mindset: Numbers you must know

• Network: A standard Top of Rack (ToR) switch handles 40-100 Gbps. A standard server NIC is 10 Gbps (roughly 1 GB/s).
• Disk I/O: Spinning HDDs give you ~100 IOPS and 100 MB/s sequential read. SATA SSDs give you ~100,000 IOPS. NVMe SSDs push 500,000+ IOPS and several GB/s.
• Memory: RAM latency is ~100ns. Reading 1MB sequentially from memory takes ~250 microseconds.
• Compute: A modern CPU core can handle roughly 1,000 to 10,000 basic web requests per second, depending on payload and TLS overhead.

The four-step NALSD framework

1. Requirements & SLIs: Define the scale. Queries per second (QPS), payload sizes, read/write ratios, and availability targets (e.g., 99.99%).
2. Single Machine Limits: Design the system for exactly one machine. Calculate what breaks first. Does the NIC saturate? Does RAM fill up? Do you hit IOPS limits?
3. Scale Out (The BOM): Divide your total global load by the capacity of your single machine bottleneck. This gives you the absolute minimum number of machines required.
4. Failure Domains & Redundancy: Apply N+1 or N+2 redundancy. Distribute those machines across racks, clusters, and geographic regions to meet your availability target.

Deconstructing a problem: Global CTR calculator

Imagine you're asked to design a system that calculates the Click-Through Rate (CTR) for all Google ads globally in near real-time. First, define the scale. Assume 10 billion ad impressions per day and 100 million clicks. That translates to roughly 100,000 impressions per second. If each event payload is 1 KB, you're looking at ingesting 100 MB/s. A single 10 Gbps NIC can comfortably handle 100 MB/s (which is ~1 Gbps, leaving 90% headroom), meaning network bandwidth at the ingestion layer isn't the immediate bottleneck for a single machine.

Writing 100,000 events per second to disk, however, is a different story. A standard SATA SSD handles roughly 100,000 IOPS. If you write every event individually, a single drive will max out immediately, leaving zero room for background tasks, OS overhead, or traffic spikes. To fix this, you batch writes in memory (e.g., 100 events per batch), reducing IOPS to 1,000 per second. Now the disk easily handles the load. But memory becomes a risk: if the machine dies before flushing the batch, you lose revenue data.

To safely ingest this traffic without dropping data, you need a distributed message queue like Kafka. Based on our batching math, one machine could technically handle the throughput, but it represents a single point of failure. If we require 99.99% availability, we need geographic redundancy. We place clusters in three distinct datacenters (e.g., US-East, US-Central, US-West). To guarantee high availability across three zones using N+2 redundancy, if our base requirement is 3 broker nodes per region for partition replication, we provision 5 nodes per region. Our final BOM for the ingestion layer becomes 15 machines globally, each with 10 Gbps NICs, 64GB RAM, and 2TB NVMe drives.

Handling live math with AcePrompt AI

Trying to keep track of IOPS, network bandwidth, and storage capacity while actively talking to a Google interviewer is incredibly taxing. That's where AcePrompt AI steps in as your real-time copilot. It listens to the specific constraints of your interview and instantly surfaces the correct hardware calculations and bottleneck analyses right on your screen. This ensures your Bill of Materials is always mathematically sound without breaking your focus.