Altruist·Software Engineer·Onsite - System Design / Architecture
May 2026
System design round at Altruist for a Software Engineer role, focused entirely on building a rate limiter from scratch. The interviewer walked me through progressively harder versions of the problem, starting simple and then pushing on memory, concurrency, and distributed scaling. Pretty dense session.
- How would you design a basic sliding-window rate limiter for an HTTP API? Walk through the data you store per client, how you decide to allow or reject a request, and the time and space complexity.
- What breaks down with the naive sliding-window approach when you have millions of clients each sending many requests per second?
- Redesign the rate limiter using a token bucket with lazy refill. What do you store per client, and how does the lazy refill calculation work when a new request arrives?
- How do you handle concurrent access to a single client's rate-limit state when multiple threads are involved?
- How would you evict inactive clients so your in-memory structure doesn't grow unbounded over time?
- How would you extend this design to work across multiple application servers?
“I started with a list of timestamps per client and just pruned anything outside the window on each request.”