System design interviews are a conversation you have to steer

The first box appears on the whiteboard before the interviewer has finished describing the product. A queue follows, then a cache and several databases. Five minutes later, traffic, payload size and the cost of a regional outage remain unanswered.

System design is an oral examination with boxes attached. The system and ML-system design track lets you practice the questions and tradeoffs that surround the diagram. Keep a notebook beside you for the boxes because the session concentrates on the conversation.

Requirements buy you room to think

Begin with users and operations. Ask what they create or read, how quickly the result must appear and which failures matter. Clarify the expected scale and whether the interviewer cares more about a broad architecture or one difficult component.

These questions keep the design tied to the prompt. A messaging system with durable delivery and a feed that tolerates delayed updates make different promises. You should know which promise you are protecting before choosing a database.

Requirements also give the interviewer a chance to steer. If they say image processing is outside scope, leave it outside. Candidates burn time solving adjacent problems because those boxes happen to be familiar.

Approximate the load before buying machinery

Begin with rough arithmetic. Calculate writes per second, peak traffic, storage growth and bandwidth with assumptions you can explain. Keep units on the page so a daily count does not accidentally become a per-second figure.

The result should change the design. A working set that fits comfortably on one primary and a replica creates a different conversation from a global service ingesting a sustained stream. Starting with Kafka, Cassandra and 14 microservices for a team task list mostly proves that you remember their names. The Capacity Estimation interview stays with this calculation until the architecture has numbers underneath it.

Say where the estimate is weak. Perhaps payload size varies wildly or a traffic spike depends on a scheduled event. You can design a safe first version and name the measurement that would trigger the next change. That sounds like engineering because it gives the architecture a reason to grow.

Storage choices carry consequences

Choose storage based on access patterns, write behavior and consistency needs. Explain which queries must be fast, what must be transactional and how long data lives. “SQL or NoSQL” is too broad to carry the answer by itself.

An interviewer may take you into B-trees, LSM trees or distributed key-value stores. Keep connecting internals to behavior. Write amplification, compaction and range scans matter when they affect the workload in the prompt. The first Storage Layer interview works through those choices in the context of a workload, where a recital of storage-engine vocabulary cannot carry the answer.

Caches require the same honesty. State what is cached, the expiration or invalidation method and what a miss costs. Then discuss stale data and failure. “We will add Redis” is a box. The useful answer explains which pressure Redis removes and which new failure it introduces.

Distributed systems make the promise explicit

Place the system inside a network partition. Name the behavior when communication between nodes fails. Does the service reject a write, accept it for later reconciliation or direct traffic elsewhere? Tie the choice to a user-visible promise and the cost of breaking it.

Consistency models become easier to discuss with one operation. A user changes a username, sends a message or transfers ownership of a resource. Explain who can see the new state, how long older state may remain and which conflict rule applies. The CAP and Consistency interview gives that promise a failure scenario and asks you to defend the behavior.

Replication and partitioning should include recovery. Walk through a node failure, lagging replica or hot partition. Consistent hashing may distribute keys, but a celebrity account or large tenant can still create skew. Mention the signal that would expose it and the move you would make while on call.

Data-intensive design follows the records

Pipeline questions often involve queues, stream processors and computed metrics. Trace one record from production through processing to storage. Describe delivery semantics, retries and what happens when the consumer processes the same record twice.

For a metric pipeline, define how events are timestamped and how late data enters a completed window. For a queue, explain backpressure and the failure policy. These details matter more than drawing five products with arrows between them.

Candidates with data engineering experience should use it. If you have operated Kafka or rebuilt a broken metric, tell the interviewer what failed and which design choice you changed later. Firsthand limits are far more useful than pretending you remember every distributed-systems paper you read in a study guide.

Low-level and ML design need separate preparation

Low-level or object-oriented design asks for classes, interfaces and behavior inside a smaller boundary. Some companies run it beside the larger architecture round. If the loop includes LLD, practice modelling and code-adjacent tradeoffs. If it does not, another night spent designing parking-lot objects probably has a poor return.

ML platform interviews move toward training infrastructure, data pipelines and distributed jobs. Explain how data reaches workers, where checkpoints live and what happens when a worker dies in the middle of an epoch. You can choose a managed stack and defend that choice. Inventing a custom collective communication system without a need tends to create a very long follow-up.

The job posting should decide whether ML preparation belongs in your week. A backend role may never touch it. A platform role that supports model training may spend the whole round there.

What the track contains

The track begins with capacity estimation and common building blocks. It has two storage sessions, covering databases, key-value stores and LSM trees, followed by caching, Bloom filters and skip lists. Two distributed-systems sessions cover CAP and consistency, then hashing, replication and partitioning.

There are also sessions for data-intensive pipelines, low-level object-oriented design and ML platform or distributed training infrastructure. Choose the slice used by your interview loop. Completing every session matters much less than being able to steer one relevant design when the interviewer changes a constraint.

Bring a system you have built, even if it served a small startup, and be ready to explain what would break at ten times the load. Ask who the user is, what downtime costs and which promise the design must keep. To practice that conversation across the relevant topics, use the system and ML-system design track.