CSEP 552: Distributed Systems

Course overview

Distributed systems are central to how computers are used, from web applications to e-commerce to content distribution. This course covers the abstractions and implementation techniques behind them: client-server computing, replication, consensus, sharding, and distributed transactions. Topics include remote procedure call, preventing and finding errors in distributed programs, maintaining consistency of distributed state, fault tolerance, high availability, and scaling.

Alumni of this course say it is among the most intellectually challenging courses they have taken at UW. We believe the best way to learn the material is to implement the ideas presented in the course, so there is a substantial programming project.

The calendar has the week-by-week topics, readings, problem sets, and labs.

Lecture

We meet Tuesdays 6:30pm to 9:20pm in CSE2 G20. Lectures are recorded via Panopto and the recordings are available to everyone in the course. We will be grading lightly on participation in discussions, so in-person attendance is generally expected.

Course resources

• Ed discussion board
• Gradescope
• Project GitLab
• Canvas
• DSLabs paper, which describes the lab framework

Course staff

James Wilcox, instructor he/him

Email: jrw12@cs.washington.edu

I am a teaching professor here at UW CSE, where I teach everything from CSE 123 introduction to programming to CSE 505 graduate programming languages. Before joining the faculty at UW, I did my PhD here on verified distributed systems. You can find more about me on my website. Looking forward to working with you all this quarter!

Samarth Venkatesh, TA he/him

Email: samnsid7@cs.washington.edu

Hello! My name is Samarth (pronounced sum-earth) and I'm an MS student here at the Allen School. I'm a theoryhead and none of my classes this quarter have programming, but I enjoyed this course and puzzling over my designs for each lab so I'm excited to be here. Swing by my office hours if you want to talk about the course, math or theoretical CS, video games, or anything else!

Zanqi Liang, TA

Email: zanqil@cs.washington.edu

Hi, I'm Zanqi! I'm originally from Guangzhou, China, and I'm excited to be one of your TAs this quarter. I love systems programming, and lately I've also been digging into LLM post-training. When I'm away from the keyboard, I'm usually dreaming about playing guitar, so feel free to stop by office hours to chat about Raft bugs or guitar building!

Contacting the staff

The best way to reach us is to post on Ed. If your question could help other students, please make it public. You can post anonymously to hide your name from your classmates (though note that staff can still see your name). If your question is not relevant to others, you can make it private. The instructor and TAs all monitor Ed, so you are likely to get the fastest response this way. If you have a sensitive question that you prefer to direct only to the instructor, then email is appropriate.

Office hours are listed on the calendar.

Assignments

There are four kinds of work in this class.

• Labs. Four significant programming projects, due every two or three weeks.
• Problem sets. Five, due in weeks when labs are not due. These are intended to give you practice with the lecture material and prepare you for the labs.
• Design reviews and discussion. Before each of labs 2, 3, and 4 we spend part of the evening reviewing designs against a list of design questions. You submit a draft of your design on Gradescope by 11:59pm the Monday before, and exchange it with other students in the room. Drafts are graded on completion: it exists, it addresses the posted design questions, and you bring it.
• Readings. Three papers, one each in weeks 4, 6 and 10, each with a short written response on Gradescope due 11:59pm the Monday before the meeting that discusses it.

See below for more on each kind of assignment.

Labs

The core of the course is to build a highly available, scalable, fault-tolerant, transactional key-value store. Key-value stores are widely used in cloud computing. The project is written in Java, derived from a similar one designed for the MIT graduate distributed systems course. A hallmark of our project infrastructure is extensive support for thorough testing and debugging. Each lab has a model-checking test suite that you can use to validate your implementation.

Lab 0 and Lab 1 are done individually. (Note that lab 0 has nothing to turn in.) For labs 2 through 4, you may optionally work with a partner.

The labs are autograded by a model checker, which is a program that exhaustively tests your solution in all cases up to a depth bound. Therefore, your solutions have to work in all cases.

The best way to write code that works in all cases is to think the design through carefully before writing any code. Design before code matters especially in distributed systems, where the number of possible code paths is exponential in the number of messages, the cost of an uncaught error in production is enormous, and testing cannot catch every case.

We encourage you to design before coding and to write the design down, for yourself and your partner. The in-class design reviews are where you get feedback on it from the staff and from other students, against the design questions we post for each lab. You may find you need to revise the design once you write code, but try to minimize that.

Start early. Many students underestimate the labs and leave too little time. The most common comment about the labs is that students wished they had started sooner.

Problem sets

Problem sets are submitted on Gradescope and done individually. We will release problem sets at least one week they are due. Most problem sets help you think through an upcoming lab or practice with other lecture material.

Readings

There is no required textbook. We assign three research papers over the quarter, listed on the calendar in weeks 4, 6 and 10, and link background reading from each lecture's materials.

Reading papers is a skill. At first it can seem hard, since papers assume knowledge you may not have yet; with practice it gets easier, and in positions of technical leadership you will be expected to read and judge recent research. The readings in this course are a low-stakes place to practice.

Grades

The class is graded on an additive points system.

• Lab 1: 160 points (the lab 1 tests sum to 320, so for this lab points are divided by 2)
• Lab 2: 330 points
• Lab 3: 355 points
• Lab 4: 495 points (part 1: 45; parts 2 and 3: 450)
• Problem sets: 360 points total
• Participation and discussion: 150 points (design drafts for the four design reviews, 25 each; 50 at the instructor's discretion for participation over the quarter)
• Readings: 150 points (three readings, 50 each)

Total points possible: 2000

There is no midterm or final exam.

The course is not curved. Your grade on the 4.0 scale is computed by the following formula.

In other words, your grade comes from this table:

This grading scheme may be unfamiliar. We will discuss it during the first class ; be sure you understand it, and ask any questions you may have.

One consequence of additive points is that, in a sense, every assignment is optional. If you cannot complete some assignment, make sure to complete the rest; there is room to miss points and still earn a good grade. Missing 6% of the available points is still a 4.0, and missing 15% is still a 3.5.

You and your optional partner receive the same points for your combined work on labs 2 through 4, so when matching with a partner, talk about your grade target. If your partner wants to do much more or less work than you do, contact the staff.

Most students complete all of the assignments to a high standard, but the assignments take real effort. Students find the class time-consuming but rewarding, and grades are generally high.

A grade of 2.7 or higher is required for the course to count toward PMP degree requirements. Graduate students taking the course S/NS receive S for a 2.7 or higher; that is 1360 points.

Late policy

Our late policy gives you flexibility without asking permission in most cases, while letting us grade and return work promptly. If something outside your control keeps you from finishing on time, contact the staff; we can usually work something out.

Each kind of work has its own late policy.

• All work, regardless of policy or extension, must be turned in by 11:59pm on Thursday, December 17, 2026, unless the instructor has given you specific, individual permission.
• Each lab has a 48-hour grace period during which work is accepted without penalty. After that we deduct 1% of your score on that lab for each additional day. If you are making progress, even slowly, keep working; if you are stuck, turn it in. Late work cuts into the time you have for the next lab, so use this only when you need it. To turn in a lab after the grace period, contact the staff.
• Problem sets have a 48-hour grace period during which work is accepted without penalty. No credit after that.
• Reading responses and design drafts are due 11:59pm on the Monday before the meeting that uses them, and are accepted until that meeting starts at 6:30pm Tuesday. No credit after class, since the point is to be prepared for the group discussion.

Unlike some policies you may know, there is no cap on how much grace time you use over the quarter. You can use the grace period on every lab and problem set and still get full credit.

Academic honesty

Please read CSE's academic misconduct policy.

You are encouraged to discuss all aspects of the course with, and ask for help from, the instructor, the TAs, and other students. But do not cross this line:

It is fine to share ideas, to explain your code at a high level to someone to see whether they know why it does not work, or to help someone else debug when they have hit a wall.

We will clearly identify which work is to be done with your partner versus individually.

• Lab 1 and all problem sets are individual.
• Labs 2 through 4 are optionally with a partner, arranged in advance with the course staff.
• Reading responses are individual.

AI tools

For the labs, you may ask an AI agent high-level questions about the material or why some code behaves as it does. You may not ask an assistant to produce the solution for you, or to debug or fix your code for you. For written work, such as problem sets and reading responses, you must submit your own words: do not ask an LLM to answer the questions for you. (You may use AI tools for light editing such as spelling/grammar or to give you feedback on your writing. In this case, please disclose your use in your response.)

Partner work

You may optionally work with a partner on labs 2 through 4.

The labs are difficult, and a partner can make them easier because you can talk through the design together. A partner is also a serious responsibility: your partner is relying on you to communicate and collaborate. Do not agree to work with a partner unless you are willing to commit to that.

A common misconception is that partners should "split up the work". That is usually a bad idea in this class, because the hard part of a lab is the design. It may take ten or more iterations to get a protocol right, and every part of a distributed protocol depends on every other part, so there is no way to split the design work. Plan to pair program, that is, work together synchronously, during the design phase until you are confident your protocol design is correct and you have written it down together. After that, either keep pair programming the implementation (we recommend this) or split the implementation. When in doubt, work together. When you work separately, keep a clear communication channel open.

By entering a partnership you agree, at minimum, to:

• communicate frequently with your partner in the weeks a lab is due;
• collaborate synchronously on the design and on hard implementation tasks;
• tell your partner in advance if you will be unavailable.

We take this agreement seriously and enforce it. If you flagrantly and repeatedly abandon your partner, expect a zero on the lab regardless of how much work you put in. If your partner breaks the agreement, first talk to them; if that does not work, contact the staff.

Anonymous feedback

Anonymous feedback can be sent to the instructor or TAs via feedback.cs.washington.edu.