Section 1: The Division You Must Do Aloud - Problem Understanding & Clarifications

Executive Summary: The first ten minutes of a Staff/Principal interview on an IP validation service. We decompose the prompt — then do the arithmetic it dares you to skip: 5,000,000 requests per second against a vendor API that handles 150. That 33,000× gap, computed aloud before any architecture, forces the topic's central inversion — the vendor is a data source to mirror, never a request-path dependency — while the clarifying exchanges tease country blocking away from the vendor and replace "real time" with honest freshness classes. Assumptions get written down and two reflexes get named.

The interviewer reads the prompt:

"You're at Twitter. Certain IP addresses must not be served — say, requests originating from a country where the product is banned, like China. You depend on a third-party service whose API tells you whether an IP is on the block list. The catch: that API handles maybe 100 to 200 requests per second, and Twitter serves millions of requests per second. Design the IP validation service."

Most prompts hide their trap in vagueness. This one hides it in plain sight: millions of requests per second and an API that answers 150. Candidates hear "third-party dependency," reach for the standard reflex — wrap it, cache it, retry it — and spend forty minutes decorating a design a single division would have killed. So before anything else, do the division, aloud:

Our traffic:        ~5,000,000 requests/second (12M at peak)
Vendor capacity:    ~150 requests/second (their 100–200 band)

Gap:                5,000,000 ÷ 150 ≈ 33,000×

Thirty-three thousand times more traffic than the dependency can carry. No cache narrows this and no queue absorbs it — even 0.01% of requests reaching the vendor would be 500 per second, more than triple its entire capacity. The vendor API cannot appear anywhere in the request path, in any role, at any hit rate. The per-request decision must be made locally, from data we already hold, and the vendor can only ever be the slow trickle that fills that data.

Key Insight: When a prompt hands you two numbers, divide them before you design. The 33,000× gap doesn't constrain the architecture — it is the architecture: it converts "call a validation API" into "mirror a dataset and decide locally" before a single box is drawn.

Decomposing the Prompt

With the inversion in hand, map the territory in four parts:

• What it does: Classify every request's client IP against block rules — banned countries, known-bad addresses, manual decisions — and allow or deny inline. One verb pair, five million times a second.
• Who uses it: Trust & safety and legal set the rules; a platform team runs the system; every request is a caller — the consumer is an edge middleware, not a human.
• Why it exists: Legal compliance (a banned country), abuse (botnets, credential stuffing), and scraping. Three motives — and they do not all need the same data source.
• How it's used: An in-process check at the edge on the hot path, fed by a data pipeline that runs entirely off it. Two tempos: microseconds on one side, a 150-per-second trickle on the other.

Quick check before moving on: