The Dependency That Cannot Keep Up: Designing an IP Validation Service

It's 09:14 and a request from 203.0.113.42 reaches the Frankfurt edge of a Twitter-scale platform. In about two microseconds, without a single network call, the edge decides to serve it. The IP has never been seen before, so it's quietly queued for validation. At 09:16 a scheduler — which owns the company's entire vendor allowance and spends 120 of its ~150 requests per second against a third-party blocklist API — asks about it and learns it's listed. By 09:17, all thirty points of presence deny it. The interview prompt behind this system hides one brutal division: the platform serves five million requests a second, and the one API that knows the answer handles one hundred and fifty. That's a gap of thirty-three thousand times, and everything in this design follows from refusing to pretend it isn't there.

Why Interviewers Love This Question

"Check each IP against a blocklist API" sounds like an afternoon with an HTTP client. The question is engineered to expose three traps:

• The Per-Request Call Trap: The candidate draws an arrow from the request path to the vendor API. The arithmetic says 33,000× over its ceiling, plus 50 ms on every request, plus the vendor's outages become your outages. Signal: never did the division.
• The Cache-in-Front Trap: The candidate says "Redis in front of the vendor." But the cache starts empty, the fill rate is capped at 150 per second, 100 million unique IPs show up every day — and a cache of single IPs can't match CIDR ranges or countries at all. Signal: treats a rate-limited database as a slow cache.
• The Real-Time Promise Trap: The candidate promises newly listed IPs are "blocked immediately." A check-only API at 150 requests per second physically bounds how fast you can learn anything. Signal: promises what the data path can't deliver.

The passing performance turns each trap into a design decision:

• The inversion: the vendor API is a data source to mirror, never a request-path dependency; decisions are made in-process at the edge from a compiled deny set, in about two microseconds.
• The split: country blocking — the China case in the prompt — runs on a local GeoIP database and never touches the vendor; only the bad-IP list does.
• The budget: one crawl scheduler owns the vendor allowance and spends 120 requests per second of it by priority — traffic rank times staleness — validating what traffic actually shows up.
• The honesty: freshness is promised per class — minutes for legal rules and overrides, an hour for brand-new IPs, a day or two for re-validated listings — and the fail-open exposure window is measured, not hidden.