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.

Lecture and Sections

The calendar page provides lecture and section topics, assigned readings, and lecture notes/slides. Video capture of lectures should automatically appear in Canvas shortly after the end of the lecture. We encourage students to use the video for review purposes only, as student questions are often inaudible, and despite our best effort, the capture is likely to fail to work properly some percentage of the time.

Instructor Contact and Office Hours

Project and Problem Sets

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 practice 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 is 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 June 13th at 9pm. In other words, slip days are not available for the last assignment.

If you have fallen farther than six days behind, please see or email the instructor. Generally speaking, we will work with you to help you complete as many of the labs as possible. Since the labs build on each other, we will want you to complete each lab before moving onto the next one.

Generally speaking, students who fall more than a week or so behind will not finish the last lab, and we use that as an implicit slip penalty.

Grades

• Problem sets: 15%
• Blog posts: 10%
• Lab 1: 10%
• Lab 2-4: 65%

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.

Readings

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 should be available for free for UW students; this should work automatically when you are on campus, and, if I have configured things correctly, even when off campus (with a 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.

Blogs

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 several 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, either leveraging off one of the questions we provide, or posing and answering 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, or one can 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 a dozen 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 you say something we found insightful. 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.

Due to time constraints (e.g., if a class discussion runs long), we reserve the right to change the syllabus, e.g., to drop a paper off the end. Do not leave all of your blog posts for the last two weeks, as these changes may leave you unable to finish the required number.

Discussion board

We have created a piazza discussion board to organize questions about the project.

Academic Honesty

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

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