Distributed systems have become 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. There will be no midterm or final exam. The course is not curved.
The calendar page provides a detailed syllabus for the course, including readings and assignment due dates.
The calendar page provides lecture and section topics, assigned readings, and lecture notes/slides.
For lecture, we will set things up so that your audio will be muted when you log in. Even a small amount of background noise can become distracting at scale. Instead, we'll use the chat room for asking and answering questions. There will be a TA on hand to read the chat room and if possible, answer the question directly, or if not, to interrupt me. If your question is too long to type, just post "question" to the chat board and we'll unmute you to ask it.
Sections will largely focus on the labs and you will need to attend to be able to complete the assignments.
To encourage participation, please post at least one question to the chat room during lecture or section each week. This could be at the end of the class, as in "I'm still confused about what is a viewserver." If everything is super clear (it won't be but just suppose) then instead post a simple factual statement you learned in the lecture/section - such as, "availability is a measure of the uptime of a distributed system".
The instructors and TA's will attempt to remain long enough to answer all pending questions at the end of lecture/section.
Video capture of lectures and sections, along with the contents of the chat room, should automatically appear in Canvas after the end of the lecture/section. However, this workflow is mostly untested.
We encourage students to use the video for review purposes only. Despite our best effort, it is likely the video capture may fail to work some percentage of the time and it is best to get your questions answered in real time.
| Lectures: | MWF 3:30-4:20 | Tom |
| Section AE: | Thurs 11:30-12:20 | Lanhao/Lukas |
| Section AF: | Thurs 11:30-12:20 | Yael/Samantha/Justin | Section AA: | Thurs 12:30-1:20 | Yael/Samantha/Justin |
| Section AB: | Thurs 1:30-2:20 | Lukas/Lanhao |
| Section AC: | Thurs 2:30-3:20 | Andrew/Arthur |
| Section AD: | Thurs 3:30-4:20 | Andrew/Arthur |
| Person, Role | Office Hours | |
| Any Staff | cse452-tas@cs | |
| Tom Anderson, Instructor | tom@cs | Wednesday 4:30-5:30 |
| Justin Johnson, TA | jtjohn24@cs | Monday 11:00-12:00 |
| Lanhao Wu, TA | lanhaw@cs | Monday 1:30-2:30 |
| Samantha Miller, TA | sm237@cs | Tuesday 10:30-12:00 |
| Lukas Joswiak, TA | ljoswiak@cs | Wednesday 1:30-2:30 |
| Andrew Wei, TA | nowei@cs | Thursday 4:30-7:30 |
| Yael Goldin, TA | ygoldin@cs | Friday 11:30-1:00 |
| Arthur Liang, TA | liangw6@cs | Fri 1:00-3:00 |
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. Relative to earlier versions, we have completely re-written the testing and debugging framework for the labs, and we have extended the project to include multi-key transactions. Each lab has an extensive 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.) The other labs (2-4) are to be done in teams of 2. After the introductory labs (lab 0 and lab 1), each of the other labs is due roughly every three weeks. Interspersed with the project deadlines we have several problem sets; problem sets are done individually.
We would like everyone in the class to complete the project, but we also understand that it can be difficult to predict exactly how long a particular lab will take to complete. For flexibility, we will automatically grant each group six slip days for the project assignments, for you to use at your discretion on labs 1, 2, and 3. These are calendar days - weekends and holidays count. There are no slip days for problem sets. Regardless of your remaining slip days, all assignments must be turned in by the end of the day of the final exam period for this class, at 11:59pm on June 11. In other words, slip days are not available for the last assignment.
There will be a small, per-day penalty applied to your final grade for groups who fall more than six days behind. This is in addition to the fact that, generally speaking, students who fall behind find it difficult to complete the final lab. That is, it is best to plan to use zero slip days - they are meant for unforeseen circumstances.
If you foresee going beyond your six cumulative days, please email the instructor. Generally speaking, we will work with you to help you complete as many of the labs as possible. Lab four builds on lab three, and so we will need you to complete lab three before moving onto lab four.
The course is not curved. Most students find that they are able to complete all of the assignments to a high degree of quality. We do not consider small deductions particularly significant; you can get a few points off per assignment and still get an A.
There is no textbook for this course. Instead, we will assign various tutorial and research papers; these readings are to be done before the class discussion, as we will take the papers as a starting point, not the end point, of the class discussion.
All of the readings are available for free for UW students; this should work automatically even if you are off campus (via your UW NetID). If you run into trouble, postpend offcampus.lib.washington.edu to the domain name inside the link, as in, http://dl.acm.org.offcampus.lib.washington.edu/citation.cfm?id=359563.
Readings to be completed before each lecture are listed on the course calendar.
For each of the research papers in the reading list (excluding some of the tutorials), we will post a few discussion questions a few days prior to the lecture where we plan to discuss the paper.
We would like you to practice reading the papers critically -- to try to understand them, but also to relate them to other material that you may know, or to later work that occurred after the original publication.
To that end, we will divide students into online discussion groups, one per section, organized through Canvas. Prior to the start of the class discussing each paper, students are required to post a short reply to the discussion thread in Canvas with a comment, observation, or question about the paper being discussed. You may use one of the questions we provide, or pose a question of your own. Valid posts can also take a position on a design choice in the paper, discuss the applicability of the paper to an important problem, or add some recent perspective. Posts may also pose a question about the paper, e.g., if you you found something confusing. You may also answer someone else's question. You can also explain why you don't agree with someone else's post (debate is good!).
Posts can be as short as a few sentences; a single paragraph is normal. We aren't looking for essays.
Blog posts are graded, but we use the best seven over the quarter, so you don't need to write more than seven posts (out of about fifteen papers). We will not grade any blog entries posted after the class period begins.
We grade blog posts on a three point scale, where 2 is full credit. We assign a 3 if we thought you had something insightful to say. We assign a 2 if your post convinced us that you engaged with the paper. A grade of 1 implies you should try to be more substantive.
We reserve the right to change the syllabus, e.g., to drop a paper off the end due to time constraints. Do not leave all of your blog posts for the last three weeks, as these changes may leave you unable to finish the required number. A good strategy is simply to blog one paper per week.
Please read CSE's Academic Misconduct Policy.
For the project, you are encouraged to ask for help, from the instructor, from the TA's, and from other students. A general rule of thumb is to ask for help if you remain stuck for more than half an hour.
However, do not cross this line: For the project, do not share code or text. Do not look at project solutions that might be on the Internet. Do not use someone else's code or text in your solutions. Sharing ideas, explaining your code to someone to see if they know why it doesn't work, even helping someone else debug if they've run into a wall, all that is ok.
All work on the problem set must be done individually. You may ask clarifying questions of the TA's and the instructor.
Anonymous feedback can be sent to the instructor or TAs via feedback.cs.washington.edu.