System design practice routine

Why it matters

Reading about designs builds recognition, not fluency. In the interview you must produce structure, numbers and tradeoffs aloud, under time pressure, while responding to an interviewer. A deliberate routine of timed attempts, rubric scoring and targeted review closes that gap, and the error log it produces tells you exactly which topics to revisit.

Core ideas

Session format. Pick a prompt, set a 45-minute timer and talk through the design aloud, recorded or with a partner acting as interviewer. Follow the method: requirements with numbers, API, data model, estimates, high-level design, one or two deep dives, failures and rollout. Stop when the timer ends, then spend 20 to 30 minutes on review.

Classic prompts and their core difficulty:

• Rate limiter: per-client limits enforced across many servers. Core: algorithm (token bucket, sliding window), where counters live, accuracy versus added latency, and whether to fail open or closed when the counter store is down.
• URL shortener: short codes for long links, heavily read. Core: generating unique codes without a coordination hot spot, caching popular links, redirect latency, abuse.
• Chat: one-to-one and group messages with presence. Core: long-lived connections, per-conversation ordering, delivery and read receipts, offline delivery, fan-out to large groups.
• News feed: recent posts from followed accounts. Core: fan-out on write versus on read, accounts with enormous follower counts, ranking, cache size.
• Job scheduler: run tasks at given times or intervals across a cluster. Core: leases with fencing, or idempotent tasks, so that a stalled worker cannot cause a double run; partitioning by time; retries; policy for missed runs.
• Metrics ingestion: accept time-series points from many hosts and query them. Core: write volume, aggregation and downsampling, high-cardinality labels, retention tiers, backpressure.
• Object storage: store and serve large blobs durably. Core: separate metadata and data paths, replication versus erasure coding, durability arithmetic, multipart upload, listing consistency.
• Notification fan-out: deliver messages through several channels to many users. Core: per-channel queues, provider rate limits, user preferences, deduplication, retries without double sends.

Rubric. Score each dimension 0 (missing), 1 (present but shallow) or 2 (clear and justified):

1. Requirements: functional scope and non-functional numbers stated.
2. Interface: API or contract with error and idempotency semantics.
3. Data: model and storage choices follow access patterns.
4. Estimates: arithmetic shown and used to size components.
5. Core difficulty: found early and addressed with a quantified alternative.
6. Failure handling: failing dependencies, retries, degradation, data safety.
7. Operations: observability, rollout or migration.
8. Communication: structure, time management, checking in with the interviewer. A reasonable target is 12 of 16 with no zeros; for senior-level practice, aim for consistent 2s on core difficulty and failure handling.

Review after every session. Replay the recording and ask: which assumptions were never stated? Which component lacks a justification? Which number was off by more than ten times? What happens if the busiest dependency is down? Then compare with a reference design from a credible source and add error-log entries (mistake, correct reasoning, topic to study). Re-attempt the prompt about a week later with a twist, such as ten times the traffic or a stricter consistency requirement.

Common misconceptions

• "Watching design walkthroughs is practice." Only producing a design under time pressure trains the skill; walkthroughs belong in the review step.
• "Memorize one reference architecture per prompt." Interviewers change constraints; memorized answers break, reasoning adapts.
• "A good session has no mistakes." The value is in finding them; a session without review notes was mostly wasted.
• "Cover every component equally." Depth on the core difficulty matters more than breadth across boxes.

How to approach it

Schedule two or three sessions per week for several weeks, rotating prompts so each recurs after a gap. Alternate solo recorded sessions with partner sessions when possible; playing the interviewer for someone else teaches you what a strong answer sounds like. Keep the error log in this app's notes and turn repeated errors into study tasks for the related topics (partitioning, messaging, resilience, consistency).