CSE 452: Distributed Systems

Course Overview

Distributed systems are central to many aspects of how computers are used, from web applications to e-commerce to content distribution. This senior-level course will cover abstractions and implementation techniques for the construction of distributed systems, including client-server computing, the web, cloud computing, peer-to-peer systems, and distributed storage systems. Topics will 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 that it is among the most intellectually challenging courses that they have taken at UW, and among the most relevant to their future careers. We will attempt to live up to that recommendation. We believe the best way to learn the material is to implement the ideas presented in the course, and so there is a substantial programming project.

Lecture and Sections

Lectures are MWF at 3:30 in ARC 147. We will record lectures via Panopto and make them available to all students in the course. We encourage you to attend lecture in person if at all possible.

Sections will largely focus on the labs and (unlike some CSE classes) you will need to attend to be able to complete the assignments. Sections are not recorded, but we will post slides.

Sections will meet at the following times.

Section	Time	Building	Room	TAs
AE	11:30	MUS	223	Claire
AA	12:30	LOW	105	Joshua & Timothy
AB	13:30	SMI	115	Samarjit
AC	14:30	SIG	227	Eesha & Heon
AD	15:30	SIG	227	Blake & Helena

 

Course resources

• Canvas
• Ed discussion board
• Gradescope
• Project Gitlab
• All publicly available Google drive resources
• Lab debugging guide
• DSLabs Paper
• Design docs page

Communication

In addition to in-person discussion, students and staff will communicate through the following means:

• Course Mailing List: Used by the instructors to email the class with important announcements. (All students are auto-subscribed, but be sure to check your @uw email for these messages.)
• Ed Message Board: The preferred way to ask questions about course content and homework assignments. We will aim to respond promptly to all questions during normal, working hours.
• Email: To discuss a personal matter related to the course, email James directly at (jrw12@cs.washington.edu).
• Staff Mailing List (cse452-tas@cs.washington.edu): Despite the name, this goes to all staff, including the instructor. Used for private matters not suitable for the message board. But please post all questions about course content on the message board instead.

Weekly Schedule

We have lectures Monday, Wednesday, and Friday and quiz sections on Thursday.

Monday	Tuesday	Wednesday	Thursday	Friday
9:00–9:50 OH (Samarjit) Gates 150 13:00–13:50 OH (Eesha) Allen 218 15:30–16:20 Lecture ARC 147	11:30–12:20 OH (Claire) Allen 220 13:30–14:20 OH (James) Allen 440 15:30–16:20 OH (Josh) Gates 387 (except Gates 287 on 5/19)	13:30–14:20 OH (Helena) Allen 3rd floor breakout 14:30–15:20 OH (Blake) Allen 4th floor breakout 15:30–16:20 Lecture ARC 147 16:30–17:20 OH (Timothy) Gates 121	11:30–15:20 Quiz Sections see table above	15:30–16:20 Lecture ARC 147 16:30–17:20 OH (Heon) Gates 121

The regular weekly schedule has the following exceptions:

• There are no office hours during the first week or finals week, unless a staff member announces otherwise on the message board.
• There are no activities on holidays listed on the course calendar.

See the course calendar for further details.

Course Staff

Instructor

Teaching Assistants

Assignments

There are three kinds of assignments in this class.

• Labs. These are significant programming projects. There are four total. The first lab is done individually; the remainder are done in teams of two.
• Design documents. There is one for each lab. The design doc for Lab 1 is to get you familiar with the concept. The ones for labs 2, 3, and 4 are due a week before the lab, so that we can provide timely feedback.
• Problem sets. Most of the problem sets are focused on helping you think through the labs. Some test specific lecture topics. All deadlines will be in gradescope, and you will have at least a week to complete each problem set. These are to be done individually unless otherwise noted.
• Blog posts. During the last two weeks of the quarter, we will assign and discuss research papers. Prior to class you will write a post on the discussion board about some aspect of the paper. This is due before the lecture in which the paper is discussed.

See below for more information on each kind of assignment, as well as the sections on grading, the late policy, and academic honesty.

Labs

The core of the course is to build a highly available, scalable, fault tolerant, and 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-based test suite that you can use to validate your implementation.

Lab 0 and Lab 1 of the project are to be done individually. (Note that Lab 0 does not have a turnin.) For the remaining labs (2-4), students in 452 may optionally work with a partner. (M 552 students must work alone.)

The labs are autograded by a model checker, which is a program that exhaustively tests your solution in all cases up to a certain depth bound. This means that you will need to come up with solutions that work in all cases. Except for the design document, the labs are self-grading—we give you all of the test cases we run.

The best way to write code that works in all cases is to carefully think through your design before writing any code. Design before code is especially important for distributed systems where the number of possible code paths is exponential in the number of messages, the cost of uncaught errors in production code is enormous, and it is often infeasible to catch every possible error through testing.

This is very different from other CSE classes you may have taken. If you think we are just saying that and we don't really mean it, please understand that it may take you as much as ten times as long to complete the assignments if you start writing code before you carefully think through the design with your partner. Debugging typos can be laborious but is a reality we all face. Debugging distributed system design errors by testing is extremely time consuming.

We strongly recommend you get an early start on the labs. Many students underestimate the difficulty of the assignments, and leave themselves too little time to finish before the deadline. The most common comment about the labs is that students wished they had gotten an earlier start. See below for the late policy.

Lab design documents

To encourage you to design then code, we ask for a design document for each lab, worth a sizable portion of the total value of the lab, due a week in advance of the lab's due date (except for lab 1) and then optionally revised and resubmitted with the lab. You (and your partner, if you are working with one) should complete the design document before writing any code. Of course, you may find from time to time that you need to update the design as you later write code, but you want to try to minimize that.

See the design docs page for more information about how to write a design document, including an example design doc. An example design document (for a very simple protocol we are not asking you to build) is here.

Finally, we also ask you to provide a short post-mortem with each lab: what worked for you, and what didn't.

Readings and Blogs

There is no textbook for this course. Instead, we will assign various tutorial and research papers. Although we do not have assignments directly relating to the tutorials, they are important for understanding the material in the lectures, labs, and problem sets.

In the final two weeks of the class, we will shift gears and read and discuss three research papers describing various practical distributed systems, along with a lecture or two on more recent research topics. Our goal with this portion of the class is to expose you to more of the context for how the ideas in the class might be applied.

A secondary purpose is to help make you more comfortable with reading papers. At first, reading papers can seem extremely hard, as they often assume knowledge beyond what you know. However, with time and practice, you can get better at it. Most of UW CSE's graduate classes are based on reading and analyzing papers, so if you might want to take further courses in systems topics at UW (e.g., attending the systems seminar CSE 590S, or in the fifth year masters program), this is a good, low stakes, opportunity to practice.

Being able to read research papers is also an essential skill if you want to do undergraduate research. And many companies will expect you (especially as you are promoted into positions of leadership) to be able to read and understand recent research papers, as they often suggest new avenues for improving a company's existing products.

We will ask you to submit blog posts about some of the papers. More details will be posted later.

Grades

The class will be graded on an additive points system.

• Lab 1: 160 points (note the lab 1 tests sum to 320, so for this lab points are divided by 2) + 30 design document
• Lab 2: 330 points + 60 design document
• Lab 3: 355 points + 70 design document
• Lab 4: 495 points + 60 design document
• Problem sets: 350 points total
• Blog posts: 90 total points, 30 for each of 3 papers

Total points possible: 2000

There is no midterm or final exam.

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

In other words, your grade will be computed by the following table:

Points	Grade on 4.0 scale
≥1880	4.0
≥1840	3.9
≥1800	3.8
≥1760	3.7
≥1720	3.6
≥1680	3.5
≥1640	3.4
≥1600	3.3
≥1560	3.2
≥1520	3.1
≥1480	3.0
...	...
≥1360	2.7 (grad sat)
...	...
≥1080	2.0 (undergrad sat)
...	...

This grading scheme may be somewhat unfamiliar to you. We will discuss it on the first day of lecture. Be sure you understand it, and feel free to ask any questions about it.

An important consequence the additive points-based grading scheme is that there is a sense in which every assignment is optional. If you are unable to complete some assignment, simply make sure to complete the remaining ones—we give you room to miss points and still get a good grade. For example, if you miss 15% of the available points, that is still some form of an A grade.

Since you will receive the same number of points as your (optional) partner for your combined work on labs 2-4, it is essential during partner-matching that you communicate expectations about your grade target. If you find yourself stuck in a situation where your partner wants to do significantly more or less work than you do, please contact the staff.

Most students find that they are able to complete all of the assignments to a high degree of quality, but that the assignments require a decent amount of effort. Students find the class time-consuming but rewarding, and so grades in this class are generally high.

If you are taking the class S/NS, note that per university policy, undergraduates receive S credit for any grade 2.0 or higher, while graduate students (including BS/MS students) receive S credit for any grade 2.7 or higher. Thus, an undergraduate would need to earn at least 1080 points to receive S credit, while a graduate student would need to earn at least 1360 points to receive S credit.

Late Policy

Our late policy is designed to give students maximal flexibility without having to ask us for permission in most cases, while still allowing us to grade assignments and get them back to students in a timely fashion. If you have an extenuating circumstance that causes you not to be able to complete the work on time, especially if due to something outside of your control, please contact the staff. Often, we are able to work something out that is agreeable to everyone involved.

Each kind of assignment has a separate late policy. Be sure you understand the differences.

• All assignments, regardless of late policy or extensions, must be turned in by the end of the day Thursday, June 11, 2026, unless the instructor has given specific and individual permission.

• Each lab (except the last one!) comes with a 48-hour grace period, during which work is accepted without penalty. We then deduct 1% off your score for that lab for each additional day that it is late. In other words, if you are making progress, even slowly, you should keep working on the lab, but if you are stuck you should go ahead and turn it in. Since turning assignments in late cuts into the available time you have for the next lab, only use this flexibility if necessary. To turn in your lab after the 48-hour grace period, contact the staff.

• For design documents, there is no grace period. This is because these are graded manually and quick feedback is essential.

• Problem sets have a 48-hour grace period, during which work is accepted without penalty. No credit is granted after the grace period expires.

• Blog posts are due before the beginning of the lecture in which the paper is discussed. You may turn in a blog post within 24 hours after the original deadline for half credit. After 24 hours, no credit will be given.

Note that, unlike some other course policies you might be familiar with, in this class there is no cap on how much total grace time you can use over the quarter. You can use the grace period on every single problem set and lab 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. However, do not cross this line:

Do not share code or written text. Do not look at lab or problem set solutions that might be on the Internet. Do not use someone else's code or text in your solutions or responses. Do not use AI to write design docs, lab code, problem set answers, or blog posts.

It is ok to share ideas, explain your code at a high level to someone to see if they know why it doesn't work, or to help someone else debug if they've run into a wall.

Course staff will submit misconduct cases to the university.

Some work in this class will be completed with a partner. The rest is to be done individually. We will clearly mark each piece of work as to whether it is to be done with your partner or individually. Please contact the staff if you are unsure about any part of how this policy applies to an assignment.

• Lab 1 and its design document are individual.
• Labs 2-4 and their design documents are optionally with a partner (for 452 students only, not M 552 students). You must arrange your partner in advance in consultation with the course staff.
• Problem sets are individual.
• Blog posts are individual.

Similarly, you may use generative AI tools to act as a "virtual TA". The following usages are recommended: - Check your understanding of concepts - Talk through design decisions and tradeoffs - High level debugging guidance

Finally, you may use generative AI to code small helper functions, but not large sections of code. AI agents, like humans, do the best when given a clear specification and small manageable steps. This means that the best use of your time will be on writing (and not generating) a good design doc. So if you use AI agents for systems building in the future, learning how to write a good design doc is crucial.

Partner work

452 students can optionally work with a partner on labs 2 through 4. (M 552 students will work alone.)

The labs are difficult, and working with a partner can make things easier because you can discuss the details of your design together. Working with a partner is also a serious responsibility: your partner is relying on you to communicate and collaborate effectively. Do not agree to work with a partner if you are not willing to commit to these responsibilities.

A common misconception about working with a partner is that you should "split up the work". This is usually a terrible idea, especially in this class, because the hard part of the lab is the design process. It might take you 10 or more iterations to design your protocol correctly, and all parts of a distributed protocol can depend heavily on all other parts of the protocol, so there is no way to "split up" this design work. Instead, you should plan to pair program (i.e., work together synchronously) during the design process until you are confident that you have a correct design and have written the design document together. After that, you can either continue to pair program your implementation (we recommend this approach) or you can try to split up the implementation work. When in doubt, work together synchronously. When you do work separately, establish a clear communication channel and keep each other posted about where you are stuck. Again, do not commit to working with a partner if you are not interested in pair programming.

To summarize, by entering a partnership, you are agreeing, at minimum, to:

• Communicate frequently with your partner during the weeks where design documents and labs are due.
• Collaborate synchronously on the design document and any challenging implementation tasks.
• Inform your partner in advance if you will be unavailable for communication or collaboration.

We take the partner agreement extremely seriously and will enforce it. If you flagrantly and repeatedly abandon your partner, you can expect to take a zero on the lab regardless of how much work you put into it.

If your partner breaks this agreement, first try to communicate with them about it. If that doesn't work, contact the course staff.

If you do decide to work with a partner, you can either find a partner on your own (and let us know) or you can ask us to match you with someone. We will send more information about the partnering process later in the quarter closer to lab 2.

When looking for a partner, be sure to communicate about grade expectations. Also, if you plan to opt in to W credit, you should find a partner who wants W credit as well.

452 vs M 552

The only difference between 452 and M 552 is that M 552 students must work on the labs alone.

W credit

This quarter we are continuing to offer opt-in W credit for CSE 452.

All students, whether aiming to recieve W credit or not, will need to do a substantial amount of writing for this class (design documents and blog posts).

W credit in addition requires revision of that writing. students who want W credit in 452 need to submit revised versions of their design documents for labs 2-4. The revisions should take into account staff feedback on the design, and include any updates to the design that you encountered while implementing the lab.

Anonymous feedback

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