What this prompt does
This prompt runs a timed mock system design interview focused on a distributed rate limiter, with the model acting as a tough but fair staff-engineer interviewer. It's told to ask one question at a time, wait for your answer, and push on weak spots instead of lecturing. The drill walks through six stages: forcing you to extract requirements, capacity estimation, algorithm choice and tradeoffs, backend pressure-testing including the Redis-down failure mode, limit-policy challenges, and a graded scorecard at the end.
Four variables tune the difficulty. [time_box] sets the length of the drill and when grading happens. [target_level] is the seniority bar you're graded against. [request_scale] is the traffic you must size the limiter for during capacity estimation. [backend_constraint] shapes the storage and coordination pressure-testing, including how the system behaves when Redis goes down. The drill deliberately won't hand you requirements you should extract yourself, which mirrors how real interviews start. Because it asks one question at a time and waits for your reply, the session reads like a genuine back-and-forth rather than a lecture you passively absorb.
When to use it
- You have a system design interview coming up and want realistic rate-limiter reps
- You can recite token bucket but haven't reasoned about the Redis-down case
- You want to practice extracting requirements instead of being handed them
- You're about to design anything load-sensitive and want to pressure-test your thinking
- You want a scorecard graded against a specific
[target_level] - You need practice defending algorithm tradeoffs under time pressure
Example output
The interview runs turn by turn: the model pushes you to ask clarifying questions, drives you through capacity estimation for the given scale, probes your algorithm choice between token bucket, sliding window, and fixed window, pressure-tests the backend and the Redis-down failure mode, and challenges per-user versus per-IP limits and tiering. At the time box it produces a scorecard with a verdict against your target level and three concrete fixes.
Pro tips
- Don't skip the failure-handling stage; how you handle the Redis-down case under
[backend_constraint]is where most candidates fall over - Set
[request_scale]realistically (e.g. 1M requests/sec across 200 services) so capacity estimation is a genuine exercise, not a token one - Actually answer one question at a time and think out loud; the drill is built to probe weak spots, so engaging fully is the point
- Calibrate
[target_level]to your real bar so the scorecard's verdict is meaningful rather than flattering - Use
[time_box]to practice pacing; running out of time before the backend discussion is itself useful feedback - Treat the algorithm-tradeoffs step as a chance to defend a choice, not recite definitions
