System Design

System design is the process of defining the architecture, components, modules, interfaces, and data for a system to satisfy specified requirements. It sits at the intersection of computer science fundamentals, engineering pragmatism, and product constraints.

In interviews, system design questions are intentionally ambiguous. The interviewer wants to see how you reason through tradeoffs, communicate assumptions, and evolve a design from a whiteboard sketch to a production-ready architecture. There is rarely a single correct answer — there are only answers that satisfy constraints better or worse.

This tutorial series walks through the core pillars of distributed system design: scalability, databases, caching, microservices, APIs, reliability, security, messaging, and the CAP theorem. It closes with two full case studies — a URL shortener and a real-time chat system — that demonstrate how the pieces fit together.

Every successful product eventually faces the same class of problems: traffic grows 10x overnight, a database becomes a bottleneck, a third-party API goes down, or a security incident exposes customer data. Good system design anticipates these failure modes and builds in margins for growth.

Beyond interviews, system design is the daily work of senior engineers. Choosing between SQL and NoSQL, synchronous and asynchronous communication, strong and eventual consistency — these decisions compound into the quality, cost, and operability of the final product.

A structured approach keeps the interview focused and demonstrates senior-level thinking. The framework below is used by engineers at top technology companies and maps cleanly to real-world design processes.

Functional requirements describe behavior. They are usually verbs: post a tweet, shorten a URL, send a message, process a payment. Non-functional requirements describe qualities: the system must serve 99.9% of requests under 100 ms, must survive a single data-center failure, or must encrypt data at rest.

Capacity estimation turns vague scale targets into concrete numbers. The goal is not precision; it is order-of-magnitude correctness. Use round numbers and justify assumptions.

These numbers immediately tell you that reads dominate writes, so a caching layer is essential. They also tell you that a single relational database could handle the write volume but would struggle with the read volume without replicas or a cache.

The high-level design is a conceptual map of the system. It should be technology-agnostic at first — talk about load balancers, application servers, caches, databases, and queues before naming specific products. Once the shape is agreed upon, you can substitute concrete technologies.

This canonical layered architecture separates concerns: the CDN handles static assets and edge caching, the load balancer distributes traffic, stateless app servers hold no session data, the cache absorbs hot reads, the database is the source of truth, and the queue decouples heavy work.

After the high-level design, the interviewer will push on the weakest or most interesting parts of the system. Typical deep-dive topics include data modeling, sharding strategy, cache invalidation, consistency guarantees, and failure scenarios.

Every design decision is a tradeoff. The hallmark of a senior engineer is the ability to articulate what is gained and lost. Do not present choices as universally good or bad; present them as context-dependent.

The following pages explore each pillar in depth. Read them in order if you are new to system design, or jump to the topics most relevant to your interview or project.