
π System Design Interview Classics Β· Flowchart
How a token bucket rate limiter decides whether to let an API request through, using Redis so all servers share the same counts.
Drawing diagramβ¦
Flowchart of a token bucket rate limiter: a request arrives, the client key is identified (API key or IP), the bucket is read from Redis, tokens are refilled based on time passed up to the bucket size, and if at least one token is left one is taken and the request is forwarded; otherwise return HTTP 429 with a Retry-After header.
flowchart TD
A[Request arrives] --> B[Identify client by API key or IP]
B --> C[Read bucket from Redis]
C --> D[Refill tokens for time passed, up to maximum]
D --> E{At least 1 token?}
E -->|Yes| F[Take 1 token and save bucket]
F --> G[Forward to service]
E -->|No| H[Return HTTP 429 with Retry-After]
G --> I[Add rate-limit headers to response]The classic interview design for a service like bit.ly: short code generation, fast redirects from a cache, and click analytics processed separately.
How a one-to-one chat message is delivered in a WhatsApp-style system, with sent, delivered and read ticks, and push notifications when the receiver is offline.
How posts reach followers' feeds: fan-out on write for normal users, fan-out on read for celebrities, and a ranked feed built from a cache.
The core of a ride-hailing app: drivers stream their locations, a geo index finds nearby drivers, and a matching service offers the trip to the best one.
A notification system that sends email, SMS and push messages at scale: one API, a queue per channel, user preferences, and retries.
How search suggestions appear as you type: a prefix index built offline from past searches, served from memory, and refreshed regularly.