Design a Multi-Dimensional Rate Limiter

The prompt sounds small: cap how often a caller can hit an endpoint. The word "several" makes it a senior design conversation. You get a stack of ceilings, enforced together. A caller might be allowed 10 requests a second, 100 a minute and 5000 an hour, with a per-endpoint cap on top of all three. Every limit has to hold at once, on a service running on many machines, without latency a customer can feel. Get the combine rule and the shared state right, and the design is done. Wave at "just use a counter," and the interviewer has their answer.

Each limit is easy alone. The difficulty is composing them under concurrency. One counter with a threshold is a first-year exercise. A design looks like this: three counters keyed by different windows, checked as a group, and incremented only when all pass. They update atomically while dozens of nodes race on the same caller, inside a tight latency budget. Name the dimensions, state the AND rule, say where the counters live, and make the check-and-increment atomic. That reads as someone who has run a limiter in production. Reaching for a single in-memory map doesn't.

The Zscaler angle

Zscaler is an inline proxy. Enterprise traffic runs through its globally distributed data plane, gets inspected, and is allowed or blocked before it reaches the destination. Throttling is native to what a data plane does. So a limiter prompt in this loop is close to home, and the follow-ups lean toward the product. The counters are shared across a fleet of enforcement nodes in many regions. The check sits on the hot path, so it can't cost a slow lookup. And the failure posture matters, because the limiter is inline. Name the dimensions, and say the request passes only when it clears all of them. Put the shared state where every node can reach it cheaply. Then say what happens to a request when the counter store is unreachable. A security-domain interviewer cares about fail-open versus fail-closed more than a consumer-app one would.