System Design Interview Questions

Model answer

Two endpoints: POST /links with the long URL (and an optional custom alias and expiry) returns the short code; GET /{code} redirects to the long URL.

One main table: links(code PRIMARY KEY, long_url, owner_id, created_at, expires_at). Lookups are by code, so the primary key is the only index the hot path needs.

Say the shape out loud: reads (redirects) far outnumber writes (new links), maybe 100 to 1, so the design is about fast, cheap reads. Validate the long URL and block known-malicious domains, since shorteners are a favourite tool for phishing.

Model answer

• Encode a unique number: take an id from a counter and write it in base 62 (a-z, A-Z, 0-9). Seven characters give 62^7, about 3.5 trillion codes. To avoid one counter becoming a bottleneck, each server reserves a range of numbers (1 to 10,000, then 10,001 to 20,000) and hands them out from memory.
• Random codes: generate 7 random base-62 characters and insert with a unique constraint; on the rare collision, try again. No coordination at all.
• Hashing the URL (first 7 characters of a hash) makes the same URL always get the same code, but needs collision handling anyway.

Counter-based codes are guessable in sequence, which lets people walk through every link; random codes or shuffling the counter's bits avoid that.

Model answer

Cache the code-to-URL mapping. Links almost never change, so a Redis cache in front of the database (or an in-process cache on each server for the hottest links) serves nearly all lookups from memory.

Go further out: serve redirects from a CDN or edge that caches the redirect response, so most requests never reach your servers.

Choose the status code knowingly: 301 (permanent) lets browsers cache the redirect, so repeat clicks never reach you at all, but you stop seeing them. 302/307 sends every click through you, which you need for analytics and for links that can be edited or expire.

Behind the cache, the database can be read replicas or a key-value store partitioned by code.

Model answer

Never write to the database inside the redirect. Return the redirect first, and emit a click event (code, time, country from IP, user agent) to a queue or log such as Kafka, asynchronously.

A stream processor or a batch job reads the events and aggregates them into counts per link per day, written to an analytics store (ClickHouse, BigQuery, or a counts table). Dashboards read the aggregates, not the raw events.

Losing a few events in a crash is usually acceptable for analytics, which is exactly why it is safe to take it off the critical path. Filter bots before counting, or the numbers mean little.

Model answer

Fixed window: one counter per user per minute (rate:user42:10:31). Increment on each request; reject above 100; the key expires after the minute. Cheap and simple.

Sliding window log: store the timestamp of every request and count those in the last 60 seconds. Exact, but stores up to 100 entries per user.

Sliding window counter: keep this minute's and last minute's counts and weight them by how far into the minute you are. Nearly exact with two numbers.

Return 429 Too Many Requests with Retry-After and headers showing the remaining quota, so well-behaved clients can slow down.

Model answer

A counter in each server's memory would let the user make 100 requests per server, 2,000 in all. The count must be shared: use Redis.

Make the check atomic: increment and set the expiry together, in a Lua script or a MULTI block, so two servers cannot both read 99 and both allow.

local n = redis.call('INCR', KEYS[1])
if n == 1 then redis.call('EXPIRE', KEYS[1], 60) end
return n

That adds a Redis round trip (around a millisecond) to each request. For very high traffic, servers can count locally and sync to Redis every few hundred milliseconds, accepting slight overshoot.

Model answer

The boundary resets the count, so a fixed window allows up to twice the limit around it. A sliding window fixes it by always looking at the last 60 seconds.

A token bucket gives each user a bucket of up to N tokens, refilled at a steady rate (100 a minute is one every 0.6 seconds). Each request takes a token; an empty bucket means 429. The bucket size sets how big a burst is allowed, the refill rate sets the average. Store just two values per user: tokens left and last refill time, updated in one Lua script.

A leaky bucket is the cousin that smooths output to a steady rate by queueing, useful in front of a fragile downstream service.

Model answer

It depends on what the limit protects, and you should decide in advance, not in the incident.

Fail open (allow) for ordinary API limits: a Redis blip should not take your whole product down, and a few minutes without limits is usually survivable.

Fail closed (block) where the limit stops abuse or cost: login attempts, OTP sends, expensive AI calls. Letting those through unlimited is how you get a large bill or a credential-stuffing attack.

A middle path: fall back to a local in-memory limiter on each server with a stricter per-server limit, and alert loudly. Keep the Redis call's timeout short so a slow Redis does not slow every request.

Model answer

Services publish an event ("order 123 shipped") to a notification service rather than calling SMS or email providers themselves.

The notification service looks up the user's preferences (which channels, quiet hours, language), renders a template per channel, and puts one job per channel on its own queue. Channel workers send through the providers (FCM/APNs for push, an SMS gateway, an email service) and record each attempt's status.

Separate queues per channel mean a slow email provider cannot delay SMS, and each channel scales and retries on its own.

Model answer

They wait in the SMS queue and are retried with backoff; nothing is lost because the queue holds them.

Better: configure a fallback provider and switch automatically when the primary's error rate crosses a threshold (a circuit breaker per provider).

Give messages an expiry. An OTP or "your driver has arrived" is worthless after a few minutes and must be dropped, not delivered an hour late. A shipping update can still go out.

Optionally fall back to another channel: if SMS fails for a delivery alert, send a push.

Model answer

Deduplicate in the notification service, not just by hoping producers behave. Give every event an id (or derive a key such as order123:shipped), and before sending, insert (dedup_key, channel) into a table with a unique constraint, or SET NX in Redis with a TTL of a day. Only the first insert sends.

Do the same at the send step with the provider's idempotency key where supported, because the worker itself can retry after a crash.

Keep a cap per user too ("no more than 5 marketing messages a day"), which also limits the damage of bugs nobody thought of.

Model answer

• Build the audience ahead of time: compute the list of user ids before 9am, not with 10 million database queries at 9:00.
• Fan out through the queue in batches: a job splits the list into chunks of, say, 1,000 users, and workers process chunks.
• Respect provider rate limits with a shared token bucket per provider, and keep marketing traffic on a separate, lower-priority queue, so OTPs and order updates are not stuck behind it.
• Spread it out: sending over 30 to 60 minutes is usually fine for marketing and avoids the app spike when 10 million people tap at once.

Also check what happens next: 10 million push notifications can mean a million app opens in minutes. Warn the teams behind the app's home screen.