The System Design Decision Tree: Classify Any Interview Question in 5 Minutes

Bucket 2: Write-Heavy Systems

The diagnosis: Data pours in constantly, at high volume, often faster than any single machine can absorb. Reads still happen, but ingestion is the hard part.

Classic examples: Logging and metrics platforms (think Datadog), IoT sensor networks, chat message history, clickstream analytics, ad impression tracking.

What breaks first: Write throughput. A single database can only commit so many writes per second. Push past that limit and latency climbs, queues back up, and data starts getting dropped.

The patterns to reach for:

• Sharding. Split data across many database servers so each one handles a slice of the write load. Ten shards means roughly one tenth of the writes per machine.
• Message queues. Put a buffer (Kafka, RabbitMQ, SQS) between producers and the database. The queue absorbs spikes, and consumers write at a steady, sustainable rate.
• LSM-tree databases. Databases like Cassandra are built for fast writes. They append to a log instead of updating data in place, like jotting notes in a journal instead of rewriting a filing cabinet.
• Batching. Group many small writes into fewer large ones. Writing 1,000 rows once is far cheaper than writing 1 row 1,000 times.

How to say it in the interview: "This system ingests millions of events per second, so writes are the core challenge. I'd put a message queue in front to absorb bursts, shard the storage layer by device ID, and choose a write-optimized store like Cassandra."

Bucket 3: Real-Time Systems

The diagnosis: The value of the data decays in seconds. A chat message that arrives five minutes late is a failure. A driver location that updates once a minute makes the map useless. The core challenge is delivering updates to users the moment they happen.

Classic examples: WhatsApp, Discord, Uber's live tracking, Google Docs collaboration, live sports scores, multiplayer games, stock tickers.

What breaks first: The request-response model itself. Normal web traffic works like sending letters: the client asks, the server answers, the connection closes. Real-time systems need an open phone line instead.

The patterns to reach for:

• WebSockets. Keep a persistent, two-way connection open between client and server so the server can push updates instantly.
• Pub/Sub. Let services publish events to topics and let subscribers receive them immediately. This decouples who produces updates from who consumes them.
• Push over pull. Don't make clients ask "anything new?" every second. Push changes to them when changes happen.
• Presence and connection servers. A dedicated fleet whose only job is holding millions of open connections and routing messages to the right one.

How to say it in the interview: "Message delivery here needs to feel instant, so I'd use WebSockets for client connections, a pub/sub backbone to route messages between servers, and a presence service to track who's connected where."

Bucket 4: Correctness-Critical Systems

The diagnosis: The system must never double-charge, double-book, or lose a record. Speed matters, but correctness is non-negotiable. Nobody praises a payment system for being fast if it occasionally charges a card twice.

Classic examples: Payment systems, Ticketmaster-style booking, hotel and flight reservations, inventory management, bank transfers, stock exchanges.

What breaks first: Your assumptions. Networks fail mid-request. Clients retry. Two users click "buy" on the last ticket at the same instant. Correctness-critical systems are hard precisely because rare edge cases become daily events at scale.

The patterns to reach for:

• ACID transactions. Use a relational database where a group of operations either all succeed or all fail. No half-completed transfers.
• Idempotency keys. Attach a unique key to each operation so a retried request returns the original result instead of executing twice.
• Distributed locks. When two users compete for the same seat, a lock ensures only one wins and the other gets a clear answer.
• Sagas. For workflows spanning multiple services, break the work into steps that each have a compensating "undo" action if a later step fails.

How to say it in the interview: "Correctness is the core challenge here. I'd use a relational database with ACID transactions for the booking flow, idempotency keys so client retries are safe, and a saga to coordinate payment and reservation across services."

Real Systems Mix Buckets. That's the Senior-Level Move.

Here's where the decision tree becomes genuinely powerful. Real systems are not one bucket. They are several buckets stitched together, and recognizing that is what separates senior candidates from junior ones.

Take "Design Uber":

• Live driver tracking is real-time. WebSockets and pub/sub.
• Location pings from millions of drivers are write-heavy. Queues and sharding.
• The payment flow is correctness-critical. Transactions and idempotency keys.
• Ride history is read-heavy. Cache it.

One problem, four buckets, four different toolboxes applied to four different components. When you decompose a system this way out loud, the interviewer sees exactly the thinking they came to evaluate: you match tools to problems instead of forcing one favorite tool onto everything.

So the full method looks like this. Classify the whole system into its dominant bucket in the first five minutes. Then, as you break the design into components, classify each component too. Say the classification out loud each time. "This part is write-heavy, so..." is one of the most reassuring phrases an interviewer can hear.

Train the Muscle Before the Interview

The decision tree only works if classification becomes reflex, and reflexes come from reps.

Here's a simple exercise. Pick any app on your phone. Ask: what is its core challenge? Which bucket does each major feature fall into? Spotify: read-heavy for streaming, real-time for what your friends are listening to, correctness-critical for subscription billing. Do this for one app a day and within two weeks the classification step will take you thirty seconds instead of five minutes.

If you want a structured path through the classic problems in every bucket, Grokking the System Design Interview walks through the canonical questions with exactly this pattern-first approach.

Key Takeaways

• Most candidates fail system design interviews from indecision, not ignorance. A classification framework removes the paralysis.
• Start every problem with one question: what is the core challenge of this system?
• Read-heavy systems (Instagram, YouTube) call for caching, CDNs, read replicas, and denormalization.
• Write-heavy systems (metrics, IoT, chat history) call for sharding, message queues, write-optimized databases, and batching.
• Real-time systems (WhatsApp, Uber tracking) call for WebSockets, pub/sub, and push-based delivery.
• Correctness-critical systems (payments, booking) call for ACID transactions, idempotency keys, locks, and sagas.
• Real systems mix buckets. Classify the whole system first, then classify each component as you decompose it.
• Say your classification out loud in the interview. It signals structured thinking in the first five minutes.

Frequently Asked Questions

What if a system doesn't fit neatly into one bucket?

That's normal, and it's actually good news for you. Identify the dominant bucket for the system as a whole, then classify each component separately as you break the design down. Interviewers reward candidates who recognize that the feed and the payment flow of the same app need different treatment.

How do I figure out the core challenge if the interviewer gives me very little information?

Ask clarifying questions aimed at the buckets: What's the read-to-write ratio? Does data need to be delivered instantly? What happens if an operation runs twice? Two or three questions like these usually reveal the bucket, and asking them is itself a strong signal.

Is this a replacement for learning the underlying concepts?

No. The decision tree tells you which patterns to reach for, but you still need to explain how caching, sharding, or idempotency keys actually work. Think of it as a map, not the territory. It gets you to the right neighborhood fast, but you still need to know the streets.

Should I mention the bucket explicitly in a real interview?

Yes, in plain language. You don't need to say "bucket." Say "this system is read-heavy, so my priority is the caching layer." Naming the challenge before proposing solutions is exactly the structure interviewers are trained to look for.

Does this framework work for senior and staff-level interviews?

Yes, and it matters more there. Senior loops are less about knowing patterns and more about judgment: choosing the right tool and defending the trade-offs. Decomposing a system into differently-classified components, and handling the seams between them, is precisely the staff-level skill.