Difficulty
Calculator
A mock senior software engineer system design round — 15 scenario-based questions (URL shortener, rate limiter, news feed, payments, caching, scaling) that probe the design decisions and tradeoffs an interviewer would ask about.
Press Check answer on each question to see whether you got it right — every check is timestamped and recorded in your Activity log below.
Each attempt is saved under its own name — load, rename, or delete them below. Difficulty / calculator tags are shared across all attempts. Numeric answers accept equivalent forms (e.g. 4/3 or 1.333).
The timer is stopped. Questions are hidden until you resume.
Medium
Answer: C — Base62-encode a globally-unique ID (e.g. an ID from a counter / Snowflake service)
Medium The service is ~100:1 read-to-write (mostly redirects). What gives the biggest latency win?
Answer: C — Put an in-memory cache (e.g. Redis) — and a CDN — in front of the database for hot codes
Medium For storing billions of shortCode → longURL rows accessed only by exact key, the best fit is:
Answer: C — A key-value / NoSQL store partitioned (sharded) by key
Medium Back-of-the-envelope: a service handles about 1,000,000 requests per day. Roughly how many requests per second is that? (nearest whole number)
req/sec
Answer: 12
86,400 seconds.1,000,000 / 86,400 ≈ 11.6, so about 12 requests/second average. (Peak traffic is usually 2–3× the average.)Hard
Answer: D — Token bucket
Hard The API runs on 20 servers behind a load balancer. To enforce a global per-user limit accurately, the counters should live:
Answer: A — In a shared central store (e.g. Redis) that all servers atomically increment
Hard A fixed-window counter (e.g. 100 req/min, reset on each minute) has which classic flaw?
Answer: C — A client can send up to ~2× the limit in a short span straddling the window boundary
0:59 and 100 more at 1:00 fall in different windows — ~200 in ~2 seconds.Hard
Answer: D — Fan-out on read (pull) — followers fetch the celebrity's recent posts at read time
Medium Which consistency model is normally acceptable for a social feed while keeping it highly available?
Answer: B — Eventual consistency — a new post may take a few seconds to appear
Medium
Answer: A — Persistent WebSocket connections so the server can push messages
Hard
Answer: D — Require an idempotency key so a repeated request returns the original result instead of charging again
Hard
Answer: A, C, D
Hard Consistent hashing is used in distributed caches and datastores primarily because it:
Answer: A — Minimizes how many keys must move when a node is added or removed
hash(key) % N, changing N remaps almost every key. Consistent hashing only remaps keys near the changed node — roughly 1/N of them — so scaling is cheap.Medium Your primary database is CPU-bound from heavy read traffic (writes are light). The most direct fix is:
Answer: A — Add read replicas and route reads to them
Hard
Answer: A — Availability — let users keep updating the cart and reconcile/merge later (AP)