1 min lesson
Infra system-design dry run
For each case in "Infra system-design dry run", name the signal and the response you would use.
Step 1 of 3
Infra design at Cursor isn't a background concern. You're drawing the foundation under a product serving 1M+ DAUs where multi-region latency, abuse-resistance and cost are first-order business problems. The design round watches whether you reason like the person who owns that.
Run one full prompt under a 45-minute clock, on a whiteboard or in a doc, narrating as you go. Use a Cursor-shaped problem so the tradeoffs are real.
Learn more
Full explanation
Drive the same six phases every time
Drive the same six phases every timeDesign protocol
Interactive diagram. Step through it with the Next and Previous controls below, or Tab to a region to read its detail.
Cost/reliability is the gate - the call you make explicit there is what the panel is really watching.
For the rate-limiting prompt, the algorithm choice is where strong candidates separate. Name the tradeoff out loud rather than defaulting to whatever you used last.
- Algorithm
- Token bucket
- Strength
- Allows controlled bursts; simple per-key state
- Cost / weakness
- Tuning burst vs rate is fiddly; needs shared state across edges
- Algorithm
- Sliding window log
- Strength
- Most accurate count over the window
- Cost / weakness
- Stores every timestamp - memory blows up at 1M+ DAU
- Algorithm
- Sliding window counter
- Strength
- Near-accurate, cheap fixed memory per key
- Cost / weakness
- Slight approximation at window edges
- Algorithm
- Fixed window
- Strength
- Cheapest to implement
- Cost / weakness
- Lets a 2x burst through at the window boundary
| Algorithm | Strength | Cost / weakness |
|---|---|---|
| Token bucket | Allows controlled bursts; simple per-key state | Tuning burst vs rate is fiddly; needs shared state across edges |
| Sliding window log | Most accurate count over the window | Stores every timestamp - memory blows up at 1M+ DAU |
| Sliding window counter | Near-accurate, cheap fixed memory per key | Slight approximation at window edges |
| Fixed window | Cheapest to implement | Lets a 2x burst through at the window boundary |
At Cursor's scale, sliding-window counter is the usual sweet spot; say why you'd pick it over the log.
Distributed rate limiting has a state problem they will probe: do you check limits at each edge with local counters or against a shared store like Redis? Local is fast but lets users exceed the global cap by hitting many edges; shared is accurate but adds a network hop and a dependency. Name the tradeoff and pick based on whether the limit is a hard abuse ceiling or a soft fairness control.