How to Study for This Course

Most of the problems we work on in this course do not have a single correct answer. Given a set of requirements, several designs can satisfy them, and the point of the exercise is not to land on “the” design. It is to produce a defensible one and be able to speak to the alternatives you did not choose and why.

This means you need two things. First, the knowledge itself: you should be able to say, for example, what a message queue is, when you would use one, and why. Second, you need to be able to put that knowledge to work: given a new set of requirements you have not seen before, propose a design, justify it against those requirements, and explain what you would have done differently under different constraints.

I recommend, for every chapter:

  1. Read the chapter notes.
  2. Rework the in-class activity or case study from that lecture on your own.
  3. Fold what you learned into your running notes.

Let’s expand on the last one.

The material in this course is not linear. We come back to the same underlying concerns (consistency, availability, latency, cost, scalability) and see them play out differently across many different topics: relational vs. non-relational databases, caching, load balancing, message queues, API design, and so on. A given lecture teaches you one instance of a cross-cutting concern (e.g., “here is how sharding trades off consistency for scalability in a relational database”), but the concern itself, and the shape of the trade-off, keeps coming up throughout the course. When you study a new topic, spend a few minutes connecting it back to an older one that shares the same underlying concern, rather than only reviewing each topic in isolation.

You can build your own study materials that pull together the different themes from across the lecture notes. For example:

  • A table of database types (relational, document, key-value, graph, columnar) with rows for consistency model, typical scaling strategy, and a good use case for each.
  • A mind map that starts from “How do I scale a system?” and branches into vertical scaling, horizontal scaling, caching, load balancing, and sharding, each with the trade-off it makes.
  • Flashcards from definitions (e.g., “What is eventual consistency?”) to conceptual questions like “You need low write latency across regions and can tolerate stale reads; what consistency model do you reach for, and why?”

Building your taxonomy of cross-cutting concerns works best if you do it in passes, revisiting and re-organizing it every couple of weeks as new material connects to older material, rather than trying to build the whole thing once at the end of the semester.

Using AI

AI can be a useful tool in this course, in a few different ways.

  • Fill in background knowledge. As noted in Approach to Instruction, this course covers a lot of material, and many topics get only a brief treatment. Students start the course with uneven prior exposure: a topic that is old news to one person may be unfamiliar to another. AI is a good way to level that out on demand. If a term or a concept from a chapter is unclear, or you want more depth or a different angle than the coursebook gives, ask an AI, rather than getting stuck or moving on without understanding it.
  • Rehearse the design skill this course tests, by using AI as an interviewer. Give it a system design prompt, and ask it to interview you the way system design interviews are usually run. If you want to focus on a particular skill you feel you need more practice with, ask it to pay more attention to that. For example, you can ask it to push you to justify your choices, by asking targeted questions or challenging your choices, or ask it to make the process more challenging, for instance by changing a requirement halfway through to see how you adapt. This is close to the format of the mock interviews in Homework, and it is the kind of practice that transfers, because you are the one doing the talking and the deciding, not the AI.
  • Quiz yourself on definitions and concepts. Point it to the lecture notes and ask it to test you cold on a set of terms or ideas. You learn more by being asked a question and coming up with the answer yourself than you do by just rereading the notes.
  • Get help building the study materials described above. Sketch your own table or mind map first, then hand it to an AI to check for gaps or push back on how you have grouped things. If you ask an AI to build the whole thing from scratch, you skip the organizing step. You learn the material by doing that organizing yourself.

One caution applies to all of this: AI can sound confident even when it is wrong or oversimplifying, especially on the kind of trade-off this course cares about, where the honest answer is “it depends.” Check what it tells you against the coursebook, and where the two disagree, the coursebook is the one you are accountable for.

Tests and the final exam are closed-book: no notes and no AI (see Exams). The mock interview is the same once it starts (see Homework). So use AI while studying in a way that gets you ready for that, not in a way that leaves you dependent on it.