Case Studies: Standing on the Shoulders of Giants

Learn from seminal work in system design to apply in novel situations in interviews and real-world problems.

We'll cover the following

When we need to design a system to solve a specific problem, two conflicting strategies might emerge:

  • The problem at hand is novel and no one has ever solved it before.

  • There is nothing new and forcing the problem to a known set of solution templates.

In some sense, these two strategies are on opposite ends of the spectrum, and reality might be somewhere in the middle. On one hand, a thorough understanding of the basic building blocks of systems is necessary, while on the other, studying how others solved specific problems guide us to see the design tradeoffs and make an informed call about which parts of our problem can be reduced to already solved problems.

Our earlier course on system design started by introducing fundamental building blocks of any modern system and its application to carefully selected design problems.

In this course, we take our system design endeavor to the next level by learning from some carefully selected seminal systems. We’ll present these systems from the first principles (meaning posing the problem at hand, thinking through different solutions, their tradeoffs, and evaluation) as a learning tool. We’ll learn many design patterns along the way, and we’ll see that such systems often challenge the conventional wisdom of solving a problem (hence their novelty).

Contributions

We bring the following contributions to make this course insightful for learners:

  • Systems have been carefully selected from a wide range of domains and have been presented to tackle evolving needs.

  • Easy-to-learn lessons have been included for you to get the gist quickly instead of reading research papers.

  • Many open questions are posed throughout the course, which might have many solutions. We often provide one solution while encouraging you to brainstorm alternatives.

  • We’ve connected different approaches to solve the same problem for a deeper understanding of the trade-offs.

  • Filtering out recurring concepts in system design wisdom sections at the end of a chapter.

Our assumptions about the learner

Since system design is the confluence of many subject areas (for example, distributed systems, computer networks, operating systems, parallel programming, and more), many concepts and associated terminology inevitably come into the discussion. While we have taken care to provide succinct definitions of such concepts and terms to jog your memory, you can also refresh them from different courses on Educative's platform (for example, Distributed Systems for Practitioners, Operating Systems: Virtualization, Concurrency & Persistence, and Grokking Modern System Design Interview for Engineers & Managers).

Bird's eye view of the course

There are 16 design problems divided into five categories (as shown below) and a special section on consensus algorithms. While each design problem is self-contained (and can be read in any order), we encourage you to read the cover page of each category first. The category cover page lesson provides a high-level view of the design problems discussed in the next many chapters, why they are important, and how they relate to each other. Problems in each category present a progression in system design with evolving needs. We have added a section on the distributed consensus algorithms that are commonly used in any large-scale system. While in the design problems, we have liberally used consensus algorithms, we have provided their details in the section on consensus algorithms.

A good system designer needs to see the big picture but also needs to be detail-oriented. We’ll observe that for some of our design problems, it was sufficient not to delve into the nitty gritty details (for example, the Colossus system). In contrast, for others, it was necessary to focus intensely on a few details to make the overall system meet our needs (for example, the SILT key-value store). As our experience with designing systems increases, we can make an informed judgment call about what level of detail will suffice.

Our design problems are primarily extracted from a few seminal research papers. Our goal is to understand a specific problem and associated trade-offs and why these systems solved them in a specific way. We hope that after taking this course, you’ll be able to identify similar problems in an interview or in your daily work, and can perform an informed evaluation about the possible solutions.

One consequence of taking design problems from a research paper is that such papers only present the novel or main ideas and leave out the rest of the system's detail. (One reason for such omissions is that there are space limitations, for example, 12 pages, and second, the primary audience of such papers are researchers and practitioners who are well-versed with the field and are only interested to know about the novel bits.) Therefore, there are many cases where specific papers have left many open questions, for which we’ve worked out a possible solution. There can be multiple solutions for such scenarios, and we encourage you to think of alternative solutions and discuss them with your peers.