</> MAANG.io
system design · 301

Advanced

Master system design interviews with scalable architecture patterns, distributed systems, and real-world design challenges.

0/480 solved 0% complete

Section 3: Thirty-Three Thousand to One - Scale Estimation & Workload Analysis

Executive Summary: This section is one division and its consequences: 5M requests a second against a 150-request-per-second vendor is a 33,000× gap that kills per-request calls, and even a 99%-effective cache in front still misses 330× too often. The budget — about 10M checks a day — can't scan IPv4 (331 days a pass) but comfortably covers what traffic actually shows: 100M daily uniques whose top 10M carry ~90% of volume. The punchline is how small the answer is: a deny set under 1 MB, a snapshot under 10 MB, a 2 µs lookup costing ~2% of a core. The napkin deletes two architectures and hands the engineering budget to the mirror and the scheduler.

The interviewer caps the marker. "Before you draw a single box: how bad is the mismatch, really?" This is the rare prompt where the first number isn't a sizing exercise — it's a verdict. Do the division out loud before anything else.

You: "Let me anchor. You said Twitter-scale: I'll use 5 million requests a second average, 12 million at peak, served from about 30 edge PoPs. The vendor — call it SentinelDB — sustains 100 to 200 requests a second; I'll design against 120, which is 80% of the 150 midpoint, keeping headroom for retries. Stop me if either end is off by an order of magnitude."

Interviewer: "Those are fair."

The Division That Ends Two Designs

Gap:        5,000,000 req/s ÷ 150 req/s      ≈ 33,000×

Thirty-three thousand times more traffic than the dependency can carry. Not 2×, where you'd batch; not 10×, where you'd cache aggressively. At 33,000×, calling the vendor anywhere on the request path is not slow — it is arithmetic fiction. That single line is D1: SentinelDB is a data source, never a request-path dependency. And it executes the obvious rescue too:

"Just cache it":  even 1% of requests missing the cache
                  5,000,000 × 1%               = 50,000 req/s to the vendor
                  50,000 ÷ 150                 ≈ 330× over its ceiling

A cache in front needs a 99.997% hit rate on day one, with a cold cache, or the misses alone bury the vendor 330 times over. Section 10 finishes this autopsy; the napkin has already told you the shape of the real answer — invert the relationship. Don't ask the vendor questions at request time; copy its answers ahead of time and decide locally.

The 33,000x gap between 5M req/s traffic and the 150 req/s SentinelDB ceiling kills both the per-request vendor call and the cache-in-front design, forcing the inversion: mirror the vendor and decide in-process at the edge in microseconds

Sign in to continue reading

The rest of this lesson is available with a free account. Signing in with Google or Microsoft is free.

Sign in to read the full lesson

Sign in to MAANG.io

Use your Google or Microsoft account — no password to remember.

Continue with Google Continue with Microsoft

Please accept the terms above to continue.