My background: 7-11 YoE full-time SWE, CS undergrad, married no kids, took 7210 as my 1st course, ended with an A.

Lectures: I found it hard to keep myself engaged with the video materials, I feel that they were just not very mentally stimulating to me. Also, I feel that they covered too many topics, the things discussed were just at the surface level.

Labs: This was where I mostly learned from the course. The labs were quite enjoyable and frustrating at the same time. I wished it would have been updated with the current version of dslabs as it has some improvements, there were times where I have to consult the current version to understand the framework more. The labs do not have much connection to the lectures though, sadly, and the labs could be done independently outside the course if one desires. While I don't have any issues with the labs schedule, I think it could be tweaked so that the first 3 labs were done in just 3-4 weeks or it could be made such that everything is released at the beginning.

Exams: I share the same sentiment with the reviews here, I don't feel that the exams were fair. They were designed to trick you with ambiguous wordings.

Time spent: lab 1 - 3 hours, lab 2 - 5 hours, lab 3 - 12 hours, lab 4 - 45 hours, lab 5 - 20 hours, lectures - 34 hours, exam prep - 3 hours

Overall, I didn't learn as much as I expected out of this course, I wouldn't recommend taking this course to learn about distributed systems -- just do the dslabs at your own time and read software engineering publications from big tech companies.

This course is not setup for your success. I am at the end of the degree and have taken 8803 Compilers and 6747 Advanced Malware Analysis, both of which stand out in their difficulty felt fair. I'll touch on lectures, tests, and labs.

Lectures: of the 8 courses I have taken, 7210's lectures are the most incoherent and scrambled. I use a notetaking app and felt like we were constantly jumping around and always needing to ask myself "what's the context we're talking about?". I do not get anywhere close to this feeling in any other OMSCS class or even any undergrad class.

Tests: similar story -> out of all other classes 7210 stands out as the worst for purposefully trying to trip up and having trick-questions. These definitely left me with a feeling that the tests do not adequately measure your knowledge, so even if you are confident in your knowledge, it's a roll of the dice if the questions will be fair. Even having open notes and open lecture materials you need to be extremely careful with the wording of the questions, and there will be questions with sub-answers that could go either way.

Labs: First few labs are extremely easy, last few are an instrument of torture only the devil would use. I enjoy difficult - the thousands and thousands of LoC for 8803 compilers, the many hours in malware analysis. 7210 labs are as difficult plus added randomness, lack of debug-ability, and need to perfectly implement your protocol or else lose a majority of points. Plus the automatic tests may reject complete correct implements based upon the data types you chose in your implementation, or if you have too much state in your implementation (and this is not explained).

The labs are focused on making distributed protocols from scratch. I would have liked to see more use-case oriented labs where we act as application-level SWEs where we use existing methods. Or even add features to existing methods.

Making the labs even more difficult is the fact that you carry over previous work of labs to the next labs. In the last lab they were kind enough to provide a partial solution to a previous lab, but this solution is inadequate to properly finish the whole lab. So once you start falling off the saddle there's no getting back up. (Seriously, just release an obfuscated jar)

This is by far the worst class I've taken at OMSCS. If you are interested in distributed computing at all, stay away from this class and just learn it on your own. You'll have a more enjoyable time and actually get to learn more without dealing with the uninspiring structure of this class.

Definitely one of the best classes I've ever taken, and also easily the hardest class I've ever taken. I burned out midway through project 5 and just left it done after part 3. Still ended up with a B.

One tip to others who may find this an easier way to work through the class-look up the original DS Labs github https://github.com/emichael/dslabs and complete as much of it yourself before the semester even begins. There are some changes between the GT version and the original, but making those changes is a lot easier than working on the project in the time frame given. I was able to complete most of project 4 by the time the semester started, and had much more breathing room, and time to learn. YMMV

great course. very hard. whoever said lab 5 is easier than lab 4 is a damned liar

This was my first class at OMSCS. My background is a B.S. in Electrical Engineering with 10 years of experience doing embedded software.

I found this class to be very hard - but hard in a good way. The product I work on is essentially a giant distributed system. Lots of embedded devices on a network all running asynchronously to manufacture stuff. In practice, I've seen a lot of nasty bugs pop up in production because the guys that wrote and designed stuff didn't understand distributed systems. They just didn't - it's a different way of thinking.

The analogy I would give is that Distributed Systems is to Concurrent Computing as Iterative Algorithms are to Recursion. It requires you to adopt a fundamentally different way of thinking. There are no locks. Time is not universal. Things will fail. I think this causes a lot of problems for many students.

This class provides you with the fundamentals that underpin the modern backend toolset. Kafka, Kubernetes, Etcd, NoSQL databases - they all use the fundamental that you learn in this class.

Overall I think the class is definitely worth it if you aspire to do backend work. Even if you don't want to work on the toolsets themselves, knowing how those tools work under the hood is beneficial.

Two gripes: 1) Project 5 is simply too much work and it detracts from being able to spend the necessary time on the papers. Suggestion to staff - pair back project 5 to parts 1 - 3. Parts 4 & 5 should be optional / extra credit for those interested.

Gripe 2) Let the test cases focus on correctness and eliminate some of the unit tests that focus on performance. E.g. Request Batching was necessary to pass some of the tests for project 4. In production this is okay, but I feel the core part of the class should be correctness - not performance. Correctness is hard enough, leave performance to other classes like HPC.

Gripe 3) We focused exclusively on strong consistency in the labs. It would have been nice to do a lab focused on eventual consistency - e.g. when bring up a server in a paxos cluster, we'd stop the world and wait for the new server to get a full copy of the log. In reality this doesn't work like this - there is some asynchronous routine that does this. It'd be nice if we had at least one lab focused on eventual consistency - maybe cut out lab 5 and do that instead.

this course is useless - do not waste time on it

This course, as well as its lab, is hard, imperfect, but useful.

The instructor has shuffled the order of some lectures, so the logical dependency between some materials is a bit broken. The lectures cover a good selection of topics, but not all of them are clearly explained. If you want to dig deeper into certain areas, you have to do some extra reading, but you may not have time to do due to the labs.

Although the labs are rescheduled and the instructor offered generous extension on demand, they are still extremely demanding if you want to pass all test cases. I, a junior programmer with a BS in CS and 2 years of professional experience, took this course as my first OMSCS course and paired it with AI4R, and I received full credits in all of the labs, so it is theoretically doable for a CS major. However, I did invest over 100 hours into the labs in total (not per week though). Since I have to work on site for 60 hours/week, the labs left me with no free time off work, and I did not have a chance to watch the second half of the lectures until project 5 was due. If you do not have sufficient programming experience or enough time budget, or if you have young children, avoid this course or give up some points. Nevertheless, the labs boosted my understanding of logical time and state consistency, taught me how to debug with distributed logs, and thus helped me a lot in my new job as a trading system developer. Therefore, I am personally very grateful for this course and the labs.

I enjoyed the labs. What I dislike are the exams, which are autograded (multi-answer) multiple-choice and fill-in-the-blank questions. I do not think they are fair: there are only 10 or so questions in each exam, but many of them are ambiguous. In the exams, I spent a whole lot of time sitting there wondering about what the questions and choices really intend to mean. The experience is not pleasant. As I mentioned above, I watched the second half of the lectures after projects 5 is due, i.e., one day before the final, and I did not do the required readings. However, I still scored above average, which also evidences that the exams are not very fair... As a graduate student, grades and exams are not that important. But when a course is as time consuming as this one, you need a fair incentive to guide your time investment, and I believe this course can further improve on this.

I feel I am speaking too much about the negative side, so I must emphasize that the difficulty and flaws of this course does not outweigh its value, at least for me. The career of an engineer is always about solving problems and overcoming challenges. New issues are never perfectly comfortable to deal with, but they help you grow as an engineer and a person, so is this course.

About me: professional full stack developer with 7 YOE., married with a young child. Bachelor's was not in CS. Took DC as my 8th course. Prior relevant courses included GIOS, AOS, and SDCC.

Time Commitment: The course starts off fairly light. The first 2 projects can be knocked out in a weekend. You can easily get by with <10 hours per week until you get to project 3. Around project 4, I was averaging 20-25 hours a week and for project 5 it was closer to 30-35. This was to get all tests to pass for every project. Each project has a few tests that are very difficult to pass. This doesn't mean the tests are unfair. Distributed systems are hard.

I'm not going to go through the specifics of each project there are plenty of reviews that cover this topic well. Spring 2021 is an outlier The class was radically changed based on the feedback from this first class. The professor and teaching staff are fairly open about how brutal that semester was. There is now more time to work on projects 4 & 5.

Search Tests are your friend This was one the best features of DSLabs. Search tests provide valuable information about what's incorrect about your implementation.

Start projects early Despite the reputation, many students wait too long to start the projects. Those that started late almost always ended up with the low scores.

Don't take this as your first class An alarming number of students were taking this or their first class or had no prior "hard" classes. I recommend taking at least GIOS or AOS prior to taking this class. It doesn't hurt to be over prepared like I was.

TA's were helpful, but don't expect hand holding I found the TAs to be responsive. Slack was fairly active with great discussion, but most students didn't really take advantage of this. There is light "hand holding" in this class. The TA's may suggest a high level strategy, but won't go beyond that.

First off, let's get this out of the way: this class is very hard and demanding. Fortunately, I think that the scheduling issues of past semesters have been resolved by the professor and TA's. That being said, it is still very difficult, but only because the subject matter itself is difficult. I felt that we had enough time to finish each project, though you definitely have to commit a lot of time to the projects, especially projects 4 and 5.

The projects themselves remain unchanged (still using DS Labs as before). The only big complaint is that dslabs uses Java, which is not the best language for a systems course IMO. The biggest thing to watch out for is shallow vs deep copies (hint: you pretty much exclusively want deep copies in the labs). Start the labs AS SOON AS THEY ARE RELEASED. I cannot state that enough. Projects 1 and 2 are ridiculously easy, project 3 is on par with probably the early GIOS projects in terms of difficulty. Projects 4 and 5 are definitely harder though not impossible. I actually used Raft over Paxos in project 4 and found I did not have many problems, though I also did not pass all the tests. most students use Paxos and the TA's even say if you use Raft to not expect much help as they all used Paxos, but I found the Raft paper easy to follow. There are a lot of edge cases in the tests, and this is on purpose - in distributed systems in the real world, those edge cases will likely happen, so you should know how to deal with them!

Overall, this course is a marathon, not a sprint. Don't expect much free time if you take it. That being said, you will learn a lot about distributed systems. And I certainly never spent 60+ hours a week on the course :) Probably 20-30 hours each week, with closer to 30ish hours a week during the later part of the course.

Overall this was a hard class. I personally think it doesn’t take as much time as what some people have said. You have to make sure you don’t spend too much time on debugging and fixing issues that won’t significantly improve your grade. I think part of reasons why the projects are time consuming is because of the limitations of the DSLabs framework. My biggest frustration with the course is that it’s not well organized. The office hours are not scheduled ahead of time which makes you feel like the instructor doesn’t care much about it.

Background

Previous courses I’ve taken: CN, DSCD, SAD, IOS, AOS, EOS, SICC. For comparison, I spent 15 hrs/week in IOS, ~20 hrs/week in AOS, ~20 hrs/week in EOS, ~15-30 hrs/week in SICC. In this course, I spent about 30 hrs/week consistently (excluding the first few weeks). I work full time (40-50 hrs/week) as a SWE but don’t have any kids.

Projects

<I don't describe the projects since other reviewers have already done that and nothing seems to have changed>

For project 3, I started the first day it was released. I averaged ~20 hrs/week. I got 85% of the tests passing about a week before the assignment was due. I spent the last week trying to get the remaining tests to pass. I couldn’t get a single one. I asked several questions on Piazza and Slack and nothing helped. Very frustrating but at least it was a B.

For project 4, I started the first day it was released. I averaged ~30 hrs/week and took 3 days off work. I was able to get 72% of the tests passing a week before the project was due. I was unable to pass any remaining tests. I was not surprised and felt defeated and slightly concerned for my final grade.

Overall

The course is extremely demanding not just because of the natural complexity of distributed systems but also because of the comprehensive test coverage for the projects. I would learn a lot within the first 2 weeks of a project - implementing the core functionality of the algorithm and passing several tests. But after this point, the learning returns diminish and frustration kicks in. Passing each additional test becomes quite difficult:

1. Debugging a distributed system is challenging [lots of messages, timing issues, multiple nodes, etc.].
2. Your code becomes fragile very quickly because of so many edge cases.
3. You may have false assumptions about the algorithm or test environment.

I’ve never taken a course where you could literally spend 20 hours working on a test case and not succeed. I’ve also never taken a class that is so difficult that a serious curve is needed [maybe one in undergrad]. If lots of students struggle with the workload and complexity [based on the uncurved grades and feedback], I think that’s a signal that the workload should be reduced; in my opinion, by eliminating a number of test cases. Relying on a curve makes it emotionally draining because you have no idea where you stand. I think this should be a non-factor with a good/mature course.

I didn’t find the TAs to be particularly helpful or active. For project 4, there was one “project office hours” but it was basically a high level explanation of the project and nothing practical like “in test X, you need to consider cases A, B and C. Let’s draw these scenarios.” Since this office hour was held 2 weeks into the project, it was already too late to be useful for what it was (an intro to the project). Other students would try to help but usually the reply was something like “I had to adjust my timers” or “I had a missing conditional”. In general, it's hard to get/give a direct answer, and in the best case, it’ll get you to think about your scenario a little differently. Because you can’t glance over each other's code or whiteboard your observations, you can easily become stuck [this happened to me many times].

I wouldn't recommend this course to most students. If you take it, you'll learn some practical things about distributed systems and you'll feel proud you completed it. However, I think it's too intense with too much depth on specific topics - like dedicating 100 hours to implement Paxos. Realistically, you'll know Paxos after 20-30 hours implementing it and passing the first 10 test cases. Sure, add in a couple extra like an unreliable network and a node failure. After that, it becomes a waste of time and quite exhausting. Sure, you can continue to debug each test case for 10 hours and try to get full test coverage. To me, that isn't learning; it's just work. An additional frustration is that this course is graded on a curve which means full-time workers compete against full-time students. I got burned out halfway through project 5 and realized I can no longer spend 10 hours to fix some edge case that works locally but will timeout on Gradescope. I decided to submit the project early, because it is mentally exhausting. I've never been so relieved to be done with a class.

Background : I have 5+ years of experience as a Software developer. I write Java daily(the language used in the class) and I have a CS background

Long story short : Avoid this class at all costs. You're better off learning distributed systems on your own and taking different classes where learning is encouraged and well supported

Most of the positive reviews here praise the class because of the topic, but not due to the quality of the course itself. Distributed Systems are interesting but losing your sanity due to this poorly structured class is not worth it.

One more way to tell that this is an awful class is that people praise it because of its curve. Generally, any class that needs a curve the size of the mount Everest to help people pass is a red flag and failure

If you think that you can do well in this class, then go to the DS labs and try to do them. In particular lab 4 and 5 : https://github.com/emichael/dslabs

Don't expect help besides the lab instructions along with passive aggressive responses like "read the paper" or "this part is easy, it took me 3 hours" from TAs. Most of the TAs belong to r/iamverysmart

For a longer review, take a look at this one : https://omscentral.com/review/-MadV1NFleLRI6w3aR9S as it basically describes my experience

This was one of the best courses I ever took. Learnt a lot and was able to score an A grade. This course can be really hard if you don't have strong programming background as the projects involves understanding a large codebase and writing code for handling various cases which is not at all a trivial to do. Overall, I learnt a lot and strongly recommend this course if your are into computing systems.

TLDR: This course is the hardest I've taken in OMSCS and I loved it.

I'll start off with 2 caveats:

1. If you don't have a strong undergraduate or industry computer science background, you will likely struggle in this course. There is no hand-holding, you will need to be able to debug 1000+ line codebases, you will need to be able to dive into a foreign codebase and understand what it's doing/asking you for, you will need to be able to pick up Java if you haven't already. None of that makes this a bad course. It just means the course has prerequisites. You are all adults who can use your own good judgement about your own aptitude.
2. If you can't or don't want to commit a considerable amount of time to the last 3 projects, you will likely struggle in this course. I agree with 5/15/2021, 4:39:02 AM's workload estimates, though I put in more time than they did on the last project to achieve a higher score. I would recommend taking this course alone, or at most paired with a very easy course (I paired with CN). Again, none of that makes this a bad course. It just means you have to be willing to put in the time. Don't take the course if you aren't.

I won't bother talking about the exams, they are trivial compared to the projects. If you are worried about taking open note exams based directly on lecture material, you are not ready for this course.

With that out of the way...

I highly agree with the reviews at 5/15/2021, 4:39:02 AM and 5/17/2021, 11:21:26 AM.

This was genuinely one of my favorite courses in the OMSCS program, primarily because it challenged me so much unlike most OMSCS courses (I loved IHPC for the same reason). Coming into this course with very little experience related to distributed computing, it truly gave me an appreciation for how difficult it is to write correct distributed applications/protocols.

I loved the DSLabs framework - you can find the original here, which was adapted for our course. It accomplished exactly what it set out to do - create a really nice environment in which you can write and test distributed applications. One of the core forms of testing in the framework - "search testing" - was completely new to me and blew my mind. The idea is to start at an initial system state, and perform a BFS or DFS search through any successor states (where a successor state is produced by delivering an outstanding in-flight message or timer in the current state) to find invariant violations. It probably isn't practical for most real-world applications, but it's one of the most thorough and perfect ideas for a testing framework in a course project, where it will actually force you to be nearly perfect in your implementation (as opposed to just managing to scrape together a somewhat working solution that happens to intermittently succeed).

I'll end by saying - please, if you don't genuinely embrace difficult problem solving with open arms, don't take this course. You will likely have a bad time, drop the class, write a bad review because it was too hard, and GT will neuter great classes like this in the future. You have already been warned.

Note 1: I marked the workload as 1 hr/wk to counter-balance the other outrageous and obviously hyperbolic 100 hrs/wk reviews. You cannot convince me you spent anywhere near 1300+ hours on this course over the semester. Realistically, an average of 10-20, maybe up to 30, hours is more reasonable, which are heavily weighted toward the second half of the semester.

Note 2: The project timing issues have been largely resolved as of Fall 2021 - we were given more time for Project 4, which seemed to have been a problem in the inaugural Spring 2021 semester.

There is nothing else that I can possibly write that would not have been covered by previous reviews by students who were also in the Spring 2021 class. After the completion of the 3rd project, I ended up dropping the class because it was just not good for my mental health. Despite knowing that there was going to be a curve, the amount of time needed to complete these assignments was approaching an absurd number.

I was spending upwards of 75+ hours a week trying to work on the very open ended projects that had no good guides or content that would relate back to the course material. It was entirely figuring out how to get DSLabs to work. It just seemed like if we had better guidance, the projects would not have been that bad. Unfortunately, this class did not have good communication from the professors or the TAs when it came to helping students with the projects. This class was entirely a "figure it out on your own" type of class, which would not have been bad if the focus wasn't the DSLabs projects.

If you are working full-time, have a family, or do not want to spend the equivalent of two full-time jobs on this class, then I would probably avoid it. There's a lot of better classes offered at OMSCS, where I feel like this is just a waste of money and definitely not worth anyone's mental health.

Just a word of advice for anyone trying to pair this with another class, don't. This class consumes so much time that you will end up ignoring work for your other class as you try to prioritize which assignments deserve more of your time.

I wanted to address some of the below points that I fundamentally disagree with, in evaluation of this course.

I don't think the course in its current form is excellent, solid, or well-supported. Saying these things and then stating that the instructions were unclear and the requirements were not expressed in such a way where we can understand WHAT we are supposed to be doing, is a contradiction. I want to be clear. These labs are ambiguous and vague and that is a failure of the course and the class. That is one thing that makes this class not "solid" or "excellent" and I fundamentally disagree with these statements saying so. I have taken plenty of classes in OMSCS and the projects and labs are very clear and able to be understood. The DSLabs in this course are the antithesis of clarity and copying and pasting them into 7210 without additional clarification or support from the instructors is a complete FAILURE of this class which is not excellent or solid in any way.

Additionally, the unit tests in these projects are not clearly commented on the intention of what they test which directly contradicts common TDD principles and generally is just a terrible practice from an instruction standpoint and the labs themselves say "we won't tell you what the tests do but in the real world you would have to code these yourself so be thankful" and what a load of garbage. "In the real world" first of all is apples and oranges with academics and secondly in the real world any decent developer or engineer would comment their unit tests to state the intention of those tests on the code. Now, this may be just a failure of the DSLabs framework but here is the thing. DSLabs is a FRAMEWORK not a plug and chug course content. I think DSLabs was meant to be a framework and starting point but its not a class in and of itself and 7210 decided it was and just copy pasted the labs into the course and then told us to do them. This is lazy and I expect better from a top institution like Georgia Tech. Not only were the labs just copy pasted into the course, but there was NO SUPPORT in any meaningful way from the instructors or TA's during this semester. It has been stated by others but basically we had no real office hours over the course of this semester and instead were told to put all the class' questions into a single Piazza thread where you might get some passive aggressive half ass answer a day later or be told to clarify your question so they can give you a half ass answer later. It was constant punting of responsibility by the TA's to do the bare minimum to help students and it is frankly embarrassing to the reputation of this institution to have such poor quality support and help in such a difficult course. So to put it shortly, the labs are copy pasted from a framework that was not likely meant to be an all up class in and of itself and then they decided to offer no meaningful support for the projects and they added no intentional additional clarity to what we were even supposed to be doing in the assignments. Maybe this will improve in future semesters but I just want people reading these reviews to understand the gravity of what you are getting yourself into with this course. Unless there are significant changes, this course is a hot mess and is far from excellent or solid, as stated by other reviews.

To note: this course is offered on campus at University of Washington but they have approximately 10 office hours a week to meet with TA's and get help. Maybe this was not feasible for our semester, but no attempt was even made to offer ANY meaningful support and that is a complete failure of this poorly constructed course.

I mean just read these reviews... People say the class is excellent then offer paragraphs of details on why the class was awful. Sounds like Stockholm Syndrome to me. I am in a different class this summer, for comparison, and I was over the moon joyous when I found out we had 5 TA's with 5 hours of office hours a week where you could hop on BlueJeans with a TA and go over your project and get help. I was also over the moon when I asked for help on Piazza and the professor responded with ACTUAL help and assistance to get me on the right track. I am not exaggerating when I say NONE of this was something I experienced in 7210 and this is NOT the norm for OMSCS classes to just have AWOL TA's and instructors who cannot muster the slight burden to actually help their students with assignments.

Speaking of which, another student that reviewed this course said “for experienced engineers, not students.” Ok, well just a little bit of information for folks writing and reading these reviews, in the context of a Master's program we are all STUDENTS who are taking classes in things we may or may not know much of anything about. Saying a class is for seasoned engineers and not students is a complete FAILURE of the course as a whole, full stop. I cannot believe it is able to be said a CLASS is EXCELLENT when also saying it is NOT for STUDENTS in an ACADEMIC setting and PROGRAM. Just insane to me to even think on. Folks need to go back to the drawing board on this one and think about it more. Obviously, it was also stated students had mental health concerns in the course which needs to be taken seriously but is also a complete failure by the course and an indication it is not excellent or solid. I don't know why I even have to type this out but this is where this class takes us.

If a class has a lot of rough edges and triggers a lot of desperation, anxiety, depression, and uncertainty, guess what? It's not an excellent course. I am so tired of seeing reviews saying this class is great while immediately listing all the reasons it was terrible. Just take it from an unbiased angle and compare it to other courses in the program and it is easy to see it was a complete failure for instruction and teaching.

Also, if a class has to depend on a curve the size of Mt. Everest then that is not an indication of success in the class. Sure, people made A's and B's but the class should get you there without much adjustments or otherwise it is an indication of failure with the instruction.

So in conclusion, if you are reading these reviews, I just want you to know that if you are thinking "oh this class might be interesting or fun" then just don't take it. If you are thinking "I have all the time in the world and really enjoy just being driven to the brink of sanity" then absolutely take this class. It will likely be improved over time but I just think it is worth noting all these "positive" and "realistic" reviews below are saying it was great but then listing all the reasons it was not and I think if my review is for any purpose at all, its just to let you know this class was a failure and that stating otherwise is contradiction to the truth. YMMV but I just don't see anything else as truthful.

Basically a copy paste from my post.

Nobody has elected this one before, we are literally the first batch of students to test the course.

It turns out the course is excellent and my passion on distributed systems aligns with the contents very well.

Course Contents

Let's first see what are included in syllabus:

• Introduction to Distributed Systems
• Primer of RPC
• Time in Distributed Systems
• State in Distributed Systems
• Consensus
• PAXOS and Friends
• Replication
• Fault-tolerance
• Distributed Transactions
• Consistency and Geo-Distributed Data Stores
• Peer-to-peer, Mobility
• Distributed Data Analytics
• Distributed Machine Learning
• Support for Datacenter-based Distributed Computing
• Byzantine Fault Tolerance, Blockchain
• Edge Computing, IoT

The course covers a large range of theory and real-life practices in distributed systems. While it starts from fundamentals, it also goes up to the latest edge development of the industry, including graduate level topics like consensus, replication and fault-tolerance etc.

For the suggested readings, you can find classical articles and industry showcases from the companies running the largest distributed (and geo-distributed) systems in the world. Some examples:

• Raynal and M. Singhal. Logical Time: A Way to Capture Causality in Distributed Systems (Links to an external site.). IRISA Technical Report. (up to Section 7)
• Lamport, Time, Clocks and The Ordering of Events in Distributed Systems
• Spanner: Google’s Globally-Distributed Database
• Scaling Memcache at Facebook
• Gaia: Geo-Distributed Machine Learning Approaching LAN Speeds

One of the hottest topics - machine learning - is also adapted in this course in a DS fashion. You will learn in a geo-distributed scenario, what are the advanced ways to make sure the learning system is working at most efficiency, utilizing compute power globally.

Projects

Well, I would say this course has the most hardcore projects among all the ones I studied in the program. It is even much harder than those in 8803 Compiler. You will be asked to implement a bunch of things which are critical components/concepts of a distributed system:

• Key-value stores
• PAXOS consensus
• View server
• State transition and consistency in distributed system
• Two-phase commit
• Distributed transaction
• Async message delivery in distributed system

Projects are kind of related as one would be the base of another, especially for project 4 and 5.

The only complaint I have is the instructions, which can be improved to state the project intent and requirements much better. Most time I struggle understanding what should be done and what is the expected way to do it.

There are a bunch of tests running on GradeScope to evaluate your implementation. Two types of tests to expect: The RUN tests and SEARCH tests. Search test is a relatively new concept to me. The test code is not checking if the input/output are valid, but walking through the STATEs that your program can reach and see if any invariant violation. The concept reminds me something learnt in CS6340 Software Analysis and Test, which tests for invariants of code block, loops and branches.

The search test can be very difficult to pass reliably if the logic of the implementation is not or near to perfect. Any edge case, including super trivial ones, will be caught when the test walks into a state that is violating any assumption. Compare to run tests, search tests is very efficient in finding missed edge cases, along with the DSLab framework, to wrap everything in-memory (including I/O operations).

Difficulty of projects increases tremendously after Project 3 (as of Spring 2021). The first two are quite straightforward and simple, if you have some exposure to software engineering. You implement a basic key-value store, extending the provided interface and base Application class. After that, PAXOS comes into play and you are going to scratch (to the ground) your head for over 50 hours to implement the famous consensus protocol from Lamport's thesis Paxos Made Simple. Well it feels like the "How to draw an owl meme":

For sure, you will learn A LOT at the end, when you finish all five projects. It's okay if you cannot get full score in all of them, I did not in the last one. Still, learn by coding is a good approach for studying distributed system, and computer science.

Conclusion

By striving through the course, I firmly believe that my passion is with Distributed Systems and I want to continue this journey. Go deep and go wide, that's what I will be trying to do.

I strongly recommend anyone who is interested in the topics to take this class, it is well-organized, content rich, with good support from the professor and TAs. The topics are not stale, you could even leverage most of things you learnt in your job, if you work in the cloud industry.

Also applied to be an TA in this course, see you in Fall 2021.

Largely a copy and paste from my full review here.

Distributed Computing was offered in the OMSCS program for the first time this past semester (i.e. Spring 2021) and when the course opened up for registration, a storm of newly admitted and seasoned students signed themselves up — me included. I was fully aware that I was walking into unknown territory, a bleeding edge course, and expected a lot of rough edges, of which there were many. That being said, the course is great and with some some tweaks around pacing, has the potential to be the be one of the best courses offered for students, especially those specializing in computing systems. Overview

The course quality is top-notch. The lectures are intellectually challenging, the assigned readers are seminal pieces of work, and the projects really drill the theoretical concepts. Overall, depending on your programming experience, expect putting in at least 20+ hours per week (with some students reporting anywhere between 30-50 hours).

Recommendation: If you are a seasoned engineer (with at least a couple years of programming experience under your belt) and someone who can handle ambiguity with little hand holding, then I highly recommend taking the course. But if you are just starting out in your computer science journey, then I would hold off for at least a couple semesters; take the recommended pre-requisites (i.e. graduation introduction to operating systems, advanced operating systems, computer networks) and wait until the course’s rough edges are smoothed out. As another student on omscentral pointed out, this class is “for experienced engineers, not students.” What to expect from the course

Pros

• Lectures are easy to watch and are packed in digestible ~5 minute chunks
• Assigned readings (from first half of semester) are seminal pieces of work by famous computer scientists like Leslie Lamport and Eric Brewer
• Skills and knowledge acquired directly apply to my career as a software engineer and computer scientist
• Instructors and teacher assistants are extremely professional, care about the students well-being, and quite generous with the grading curve

In this class, you’ll develop a foundation around designing and building distributed systems. You’ll understand the importance of systems keeping track of time and the different ways to implement clocks (e.g. scalar clocks, vector clocks, matrix clocks). In addition, you’ll appreciate how systems achieve consensus and being able to make trade offs between choosing different consistency models such as strict consistency, eventual consistency. You’ll end the semester with learning about the infamous CAP theorem and FLP theorem and how, as a system designer, you’ll make trade offs between consistency, availability, and the ability to withstand network partitions. Of course, you’ll eat and breathe Leslie Lamport’s PAXOS. So if any of these topics interest you, you’re in for a treat.

Cons

• Bleeding edge course means that there were lots of rough edges
• Projects were very demanding, often requiring multiple hours to pass a single test worth very little towards grades
• Triggered lots of uncertainty and desperation among students throughout the second half of the semester

As mentioned above, this class induced a lot of unnecessary stress in students. Even for someone like me, who cares less about the actual letter grades on transcripts, felt pretty anxious (this class potentially could’ve held me back another semester, since up until the grades were actually released, I had assumed I would get a C or lower). Impact on mental health

One concerned students published a post on the forum, asking if students were mentally okay:

I just wanted to check in with everyone on here in the class. I know these projects are stressful and for me it’s been something of a mental health hurdle to keep pushing despite knowing I may very well not succeed. Hope everyone is doing ok and hanging in there. Remember no assignment is worth your sanity or mental health and though we are distanced we are all in this together.

Anonymous Calc

Many other students chimed in, sharing their same frustrations

I found both of the projects very frustrating. Specially this one. I am working for last 2 weeks (spending 50+ hours in writing/rewriting) and still passing only 7/8 tests. I never had unfinished academy projects. This is the first course I am having this.

I couldn’t help but agree:

Honestly, I was fairly stressed for the past two weeks. Despite loving the course — content and rigor of the project — I seriously contemplated dropping the course (never considered this avenue before, and I’m 2 courses away from graduating after surviving compilers and other difficult systems courses) as to avoid potentially receiving a non-passing grade (got an A on the midterm but its looking pretty bleak for Project 4 with only 12 tests passing). At this point, I’ve fallen behind on lectures and although there is 1 (maybe 2) days left for Project 4, I’ve decided to distance myself from the project. Like many others, I’ve poured an insane number of hours into this project, which doesn’t reflect in the points in Gradescope. I suspect both the professor and the TAs are aware of the large number of people struggling with the project and will take this all into account as part of the final grading process.

Tips Programming Projects

Here’s a list of the projects, their weight towards the final grade, and the amount allocated to each assignment.

• Project 1 – Environment Setup – 5% – 2 weeks
• Project 2 – Client/Server – 10% – 2 weeks
• Project 3 – Primary/Backup – 15% – 3 weeks
• Project 4 – PAXOS – 15% – 3 weeks
• Project 5 – Sharded KV Store – 15% – 4 weeks

Project 1 and 2 are a walk in the park. The final 3 projects are brutal. Make sure you start early, as soon as the projects are released. I repeat: start early. Some people reported spending over 100+ hours on the latter projects.

Unless you are one of the handful of people who can pour in 50+ hours per week in the class, do not expect to get an A on the programming projects. But don’t sweat it. Your final grade will be okay — you just need to have faith and ride the curve. All you can do is try and pass as many tests as possible and mentally prepare for the receiving a C or D (or worst) on these assignments. Summary

The course is solid but needs serious tweaking around the pacing. For future semesters, the instructors should modify the logistics for the programming assignments, stealing a couple weeks from the first couple projects and tacking them on to final projects (i.e. Primary/Backup system, PAXOS, Sharded Key-Value Store). With these modifications, students will stress out way less and the overall experience will be much smoother

Despite many of the early reviews, you can get an A or B in this class without going "above & beyond."

The difficult part is the uncertainty about the curve and knowing when to stop working on a project. This is the only class I've ever taken where I was unable to pass all test cases of an auto-graded project.

My background: aerospace engineering undergrad. Industry-wise, I am lowly data-analyst with some full-stack web development experience. No prior experience with distributed systems.

Projects 1 & 2 were trivial.

Projects 3, 4 & 5 were HARD but interesting. My grades were 92, 65 and 82, respectively. I spent 30-40 hours on each.

The mid-term exam was easy; the average was around 90.

The final exam was a little more difficult with an average around 75.

"Participation" was worth 5%. I earned full credit by basically only posting once in the intro thread; however, I did read most of the other posts.

The curve--applied at the end of the course--was quite generous! The cutoff for an A was ~78. I assume anyone below this who didn't drop or give up earned a B.

In summary, I went in knowing this was a difficult course and had hoped for just a B, but I ended up earning an A. For me, this course was far more enjoyable than Machine Learning and required much less time. Make sure you have the appropriate expectations, then give it a shot!

This is the first OMSCentral review I've written. The lopsided negative reviews and crazy workload reports motivated me to throw out a (hopefully) more realistic / even-handed review.

Yes, it is much harder than most OMSCS courses; probably the hardest one I've taken (competing with Compilers, AI, CV, and AOS for that honor). To reiterate, this is a graduate degree program at one of the top tech schools in the country. If you want to get the degree with minimal effort, this course is not for you. If you want a good education, do consider taking it.

The lecture material and exams aren't terribly difficult, but the last three projects are. There is an excellent assortment of papers assigned; unfortunately I missed some later in the course due to time constraints, but hope to go back and read them. I'm a competent professional software engineer with a lot of industry experience using (not building) distributed systems (mostly in Java/Kotlin), but still spent 20-30 hours each on the last three projects to eke out grades in the mid 80s. I had not previously had that experience, and it was humbling. Fortunately the curve was very generous (I think the cutoff for an A this semester ended up ~78%!), so if you try hard and don't give up, an A or B is definitely achievable.

The material is interesting and highly relevant to a lot of industry work. If you can budget the time and prepare yourself for some very challenging hours of debugging, it's definitely worth taking.

P1 is done for you but don’t make the mistake of just turning it in. Really understand why everything works but I feel like this is a mistake with the class. No one is explaining anything. You have to look at P1 and understand a completely new framework at face value based on the lab and the poorly written write ups.

P2 is not bad but it can be tricky if you don’t fully understand the nuances of the DSLabs framework.

P3 I struggled with but overall it was ok. I did not complete it 100% because the search tests are insane.

Midterm was easy. Final was easy.

P4 was a hot mess and we only had two weeks to do it. It was basically “read this paper and code what is in this paper but not exactly what is in this paper” and I hated that so much.

P5 was more manageable but I was so burned out at that point I just didn’t want to try anymore.

This class is a mental health nightmare and the TA’s were trash. If you somehow can do DSLabs on your own before the class starts then you will be good but the class is brutal and there is no support from the instructors at all.

Material is interesting but the labs are nightmare fuel and I wouldn’t waste my time with this class had I known what I was going to go through.

Let me offer some different perspective.

This course is indeed hard, but I feel it's actually because other OMSCS courses are too easy. As someone who came from a solid undergraduate school, many of my undergraduate courses are on a similar level of difficulty, or even harder. I guess one important difference is that as part-time students, we have less time and energy to fully concentrate.

The course grades consist of four projects and two exams, plus participation.

• P1 and P2 were trivial. They can be done in a few hours.
• P3 was moderate. I spent about 30 hours.
• P4 was the most difficult one. I spent about 50 hours and managed to get a fully working solution. P4 really requires a very robust solution to pass all the tests. Debugging was a very intensive experience. I had to fully focus for a few hours to do some regex search through thousands of lines of logs and keep some complex logic in mind to identify the root cause of one bug. Then repeat the process over and over. Any distraction will make you have to start over again.
• P5 was the most time-consuming one. The logic and edge cases are not as hard or tricky as P4. It's just that the implementation is longer and has more details. I spent 40 hours and completed 70%.

Midterm was easy. I studied for a day and got a very good score. Mean was around 90. Final was harder with a mean around 75. Both were open-book. Note that the exam difficulties could change in the coming semesters.

Overall I feel this is one of the few solid courses in OMSCS. If you are interested in distributed systems, I highly recommend it. Just set your expectations right - The projects are not some trivial ones that you can sit back, relax, and work out little by little. It requires a high level of focus and dedicated debugging effort.

On the average hours per week, if I'm to be exact, I spent in total around 140 hours in the semester and there are 14 weeks, so it's 10 hours per week. But the average number is misleading. Just be prepared to spend 50-100 intensive hours on P4/P5. Also if you read all the recommended papers, it will be an additional 5-10 hours per week.

Thoughts on this class in no particular order:

• Read the 2019 dslabs paper (https://ellismichael.com/papers/dslabs-eurosys19.pdf) before starting this class. It gives a lot of context on how UW developed the dslabs framework, projects, and tests, and the authors provide some good high-level advice on how to approach the labs.

• The dslabs framework doesn't use real network traffic. No socket programming, gRPC calls, MPI collectives. All nodes and message passing are "simulated" in a (mostly) singlethreaded process.

• I took several of the programming heavy classes (GIOS, AOS, HPC, CV, etc) and this class has by far the most thorough and time consuming test suite for its projects. This is not a class where you can parameter tune some variables to "fit" the tests. You actually have to have a near-perfect design to pass all the tests consistently. Failing a test 1 out of 20 runs is a symptom of some implementation error leading to deadlock.

• Debugging distributed systems is hard, period. The framework includes a visualizer that is mostly useful for handling edge cases. A lot of debugging will require staring at 500+ line console logs to find a logic error in one of your message handlers.

• You don't need to know Java, but it's a good idea to at least know the basic OOP design principles.

• Get comfortable with Java 8 Collectives (Maps, Sets, Lists) and make sure you know how to iterate through them.

• Get comfortable with your preferred version control framework, because you will likely need to refactor labs 3-5 several times.

• You should definitely understand shallow copy vs deep copy, labs 2-5 all require writing your own deepcopy / copy constructor methods.

• You can't control the order that different clients' requests arrive at the system (clientA --> clientB OR clientB --> clientA, either is fine), but every server node in your system must agree on the same ordering.

• A lot of other reviewers here are frustrated at the pacing, TAs, grading rubric. I consider these growing pains as part of this class' first semester online. I don't think the difficulty of the labs can be turned down much without significantly deviating from the dslabs public repo, which would be a shame. Yes, this class would feel a lot better if paired programming was allowed. But in the end, Prof Ada was generous with the curve and I'm sure she will make changes to the scheduling and grade weighting to improve the overall feel of the course.

• Like others mentioned, labs 1-2 are so easy that they lull you into thinking the rest will be comparable. Don't be fooled and make sure you start early on labs 3-5. I spent 40 hours to pass 19/20 tests for lab 3, 90 hours to pass 23/26 tests for lab 4, and then 50 hours to only partially complete lab 5 (got busy with other life responsibilities).

• I recommend starting with the simplest design possible (fewest class members) to pass the basic tests for each lab. Then, add your retry timers, extra message types, deduplication checks, to handle the UNRELIABLE network tests. Every state variable, data structure, and timer you add explodes the search tests' state space, making it that much harder to debug.

• Even if you can only get 50/100 on the labs and finish with a B, there is still a lot to learn from this class. At the very least, you'll gain a sense of how difficult it is to design and debug distributed systems and consensus protocols. The breadth of research papers is great and covers a lot of modern (past decade) distributed systems technologies including those developed by Facebook, Amazon, and Google.

Spring 2021 enrollee here - the first time this class was offered in OMSCS. This was my last class in the program. This class was brutal. It was hard. My family life suffered. My "me" time suffered. However; I like challenges, and this was definitely a fun challenge; it was not a bad class at all. I enjoyed the material I learned and while the projects took more time than I had to give, overall I felt they were a fun challenge. Knowing Java will help, and if you have never touched Java before in your life, do a basic tutorial that includes things like working with collections. I also really recommend that you have taken GIOS or AOS prior to this course. If you don't already have a CS background, you'll likely spend some extra time learning core concepts in order to understand some of things in the course. DO NOT PAIR THIS COURSE. YOU HAVE BEEN WARNED.

The lecture materials (videos and readings) are complementary to each other and Ada spends time highlighting the more important aspects of the papers in the lectures, leaving reading them up to you for more detail (and you will need to read them). The projects are versions of the DSLabs Java-based projects available on GitHub. For pretty much every project except for 1 and 5, you're given mostly empty shells of Java classes and the entire implementation is up to you. START THE PROJECTS EARLY!!

Admittedly, I was not very active on Piazza, I was more active in Slack and in a Discord server. If you don't have a regular 'study group' of students that you constantly chat with and can bounce ideas off of, you should find one before getting into this class. While you can't discuss actual code, there's nothing wrong with talking strategy or design ideas. Slack is also available (like GIOS and some others, this course has it's own Slack space as well). I did visit Piazza every so often to look for answers to questions I might have though. The project threads can get full pretty quick and make it hard to find things though.

The first half of the semester involved projects 1-3 and the mid-term.

• Project 1 was a cake walk; literally copy/paste from the README to get up to speed with the framework. If you struggle at all with this project, you'll want to seriously reconsider taking this class. With the report, this took me about 1 hour.
• Project 2 was not very challenging. If you understood what you did in project 1 (or even if you didn't very much), there was some replication of what you did there except without the direction and a bit more logic/though. If you struggle with this one, you should reconsider staying in this course. With the report, this took me about 4 hours. I saw an average of around 6-8 by some other students in Slack.
• Project 3 was moderately challenging. You should be comfortable with the DSLabs framework at this point so the only direction you really get is the project readme. Make sure you understand how to use the visual debugger for the search tests, it will come in handy and make solving bugs so much easier. Including the report, I spent around 40 hours on this project.
• The midterm was probably different this semester than it might be in future ones. The midterm butted right up against the drop deadline so Ada modified the exam to make it easier to grade (and thus easier to take). The mid term was open-note as well, and the papers were available via a shared Google Drive folder.

The second half of the semester involved projects 4-5 and the final.

• Project 4 is where you're implementing Paxos. This project is challenging and complex; you can't really even start testing until you have the basic Paxos implementation done. You are given a paper that contains pseudo-code and Python to follow; however this paper assumes the 'happy path', it does not account for network partitioning, packet loss, etc. The paper will only get you so far and only passing about 3/5's of the tests, which is only worth about 40% of the project grade, after that you're on your own. I spent almost 90 hours over two 1/2 weeks including writing the report.
• Project 5 builds on top of Paxos. Fortunately we were provided a reference Paxos that supported single-server which was good enough to get parts 1, 2, some of 3 and some of part of 4. If you needed to do additional troubleshooting locally, you needed to get your project 4 Paxos working on project 5. This project took me about 40 hours to complete.
• The final was multiple choice and short answer; it was not cumulative and only covered topics since the mid term. The average on this was lower than the midterm, but that could be an artifact of people spending so much time on projects that they did not have time to study properly. Like the midterm, this was also open note.

In the end, the class was heavily curved, probably more than the instructor initially felt it might be. The A cutoff was in the high 70's, and the B cutoff was in the lower 60's. Almost half the class got an A, 80% got a B or better and 16% withdrew. This course was a huge challenge and I'm pretty sure I lost sleep some nights as did many others, but only a handful of people didn't get a B or better. That said, I would still take this course again, I enjoyed it. I like a challenge and this certainly presented one.

This class needs improvements before being offered again. In its current form, its kind of a hot mess with lacking support and clarity on the assignments. Additionally, labs would take much less time if they were just presented in a clearer manner. We are provided an ambiguous problem statement and then just told to do it and I don’t think that is appropriate for students coming in learning this for the FIRST TIME. Like what if I don’t know Paxos at all coming into this class? What if we don’t know dining philosopher’s and two phase commit? They say other computing classes are not a prerequisite but I doubt that since there was constant mention of topics from other courses like 6210 or whatever. Having not taken other computing courses before now, I felt severely disadvantaged. I will never know if taking GIOS or AOS would have helped me in this class but I don’t care to know since it was not listed as a prerequisite and more treated like a secret club of knowing things that might have helped in the later assignments and for that this class should be ashamed. The TA’s were embarrassingly unhelpful and I have never had a worse bunch of TA’s in my life. Class needs to go back to the drawing board and consider a different approach because this one did not work and anyone suggesting otherwise needs a break because they may be suffering from Stockholm Syndrome at this point.

The class is hard. I spent most of my weekends (especially latter half) working on the projects.

I believe taking other computing systems courses like GIOS, AOS, HPC helped me with this class.

Projects 1 and 2 are simple and they allow time for learning the details about dslabs framework. Project 3 has medium difficulty. Project 4 needs the students to read and understand "Paxos Made Moderately Complex" paper before implementing the lab. I read the paper multiple times to properly understand it. The understanding helped with implementation of multi-paxos. You will still need to fit the implementation into the dslabs model (event-driven + network model) and add other optimizations. Proper logging can help with understanding liveness issues in Paxos implementation. Project 5 felt implementation heavy. I spent long time thinking on the design of the project before starting the implementation. Having a working version of Paxos from previous lab can help with debugging. For most labs, I used the strategy to get some basic tests passing and then concentrate on passing the search tests.

I learnt a good amount from the lectures before mid-term. The projects took up most time after mid-term and didn't allow much time to watch the later lectures.

I felt mid-term exam was easy and final was tricky. But ended up scoring similarly on both of them.

I had a positive learning experience with the course. I recommend this course to anyone interested in distributed systems. I believe the feedback from the first run of this course will help instructors to improve the course in future offerings.

I don't think allowing groups in projects will be helpful because that may cause liveness issues.

Good that I have taken the course on it's first offering. If I had waited for the reviews, I wouldn't have taken it. It is not as worse as reviews suggested. Project 1(5%) is simple. Project 2 (10%) is simple. Project 3( 10%) is medium. Project 4 & 5 (15% each) are hard. Exams (40%) are at medium complexity. Participation (5%). 70% of the grade is at/below medium complexity. If 50% of project 4 & 5 can be completed, total grade would be at around 80% (considering losing some points in exams). I wouldn't say you would need to read all the mandatory papers from beginning to end to score well on exams. If you are able to grasp important concepts in the paper, that is good enough. You can score good enough marks just by using the content provided in the lectures. Most of the lecture do explains important concepts from paper. Exams are open book. I agree that, planning could have been better. Considering it is offered first time in online version, mistakes are bound to happen. Prof Ada was very receptive to feedback and provide extensions to all the projects. 6200 (or) 6210 are not prerequisite for this class.

Needs a lot of changes in order to be considered a feasible class. Felt like we were guinea pigs for a misery simulation and weren’t provided any support along the way.

This is a hard class, if the other reviews haven't emphasized that sufficiently yet. It's the hardest class I've taken in the program, and I've taken several of the harder systems classes (IHPC, AOS, HPCA, etc). It's also the only course I've ever written a review for, because I feel the need to counteract some of the (in my opinion) undeserved hate of some of the earlier reviews.

The projects are very difficult. Paxos is notorious for being one of the hardest algorithms to understand in computer science, and project 4 (not even the final project!) is implementing a version based off the paper Paxos Made Moderately Complex. To be successful, not only do you need to understand basically every word of the (long) paper, but you have to implement additional pieces above and beyond that: leader election, garbage collection, request batching, everything on an unreliable network that may deliver messages out of order, multiple times, or drop them all together (which is not the network model the paper uses). Furthermore, you have to translate the "separate process" model used in the paper into a single process, event driven model required by the dslabs framework you are building on.

Project 5 takes even more time, although I found it less intellectually difficult. There you have to use your Paxos implementation (or a provided black box implementation) to implement a distributed key/value store that can rebalance shards across replica groups and supports distributed multi-key transactions.

These project are hard because they require a lot of code (project 5 took me around 1500 lines of code total), seem to be a little underspecified without a lot of help to figure out a good design approach, and are difficult to debug (breakpoint debugging doesn't work in a distributed system like this where there are timers firing and multiple nodes sending and receiving messages out of order, you just have to log stuff and sift through massive logs). Some of these issues are inherent to the problem domain (debugging production distributed systems is very difficult) but some could be remedied by project readmes being more detailed or walkthroughs with more information about suggested approaches. The TAs provided this sort of helpful information in office hours, but by then I was too far in with my design to start again with the suggested design.

This class took me 20-25 hours a week. I don't cram and I don't procrastinate. I spent 3 hours every weekday (and I mean every) on this course and usually most of each Saturday. I took no breathers after projects and started immediately on the next project the day it was released. I read and re-read each lab several times before touching the keyboard, and asked questions on Piazza well before most other students, which allowed me to get answers quickly. As a result, I would say I spent less time than most on each project (projects 4 and 5 took me 50 - 60 hours each), and got above 88 percent or above on each of them. In other classes I've taken I'm used to getting 100% on projects but here I was grateful for anything I could get.

I personally prefer classes where projects are each standalone and tackle a different area of what you are learning, kind of like Software Analysis and Testing projects, because you get to explore a lot of different things and don't have to worry about mistakes made earlier affecting future projects. For a class like this, that would imply keeping projects 3 and 4 and scrapping project 5. I would have liked to implement some other things we discussed, like DHT (Chord) or transactuations, which would be ideas for future labs if a lab model like this was chosen. But for now most of the projects build on each other and are all implemented on top of dslabs.

That said, it was very satisfying to have a working, large scale system that I built myself throughout the semester. Others have said they wish partners were allowed but I'm very glad they were not. The stress of finding a partner, coordinating with them, understanding the code they write, etc, I feel would just increase the difficulty of the projects. Partners and group projects in general are just not a good fit for OMSCS, in my opinion.

This is definitely a class I would recommend. If you come into it ready to work, struggle, and manage your time, I feel you will likely be successful. Future versions of this class I'm sure will improve the things I've mentioned above so I whole-heartedly recommend it. This is the essence of what a systems course should be, with a few rough edges. You'll walk away with a deeper, visceral knowledge some of the central ideas in distributed computing, and with enough experience under your belt developing real systems to provide a foundation for future work in this area.

Wanted to wait until the course is over to review. This is a rough one for sure. The midterm and final are very doable but the lectures and exam content run tangential to the projects, which is where most of not all of the problems with the course exist.

For starters, the on campus course apparently let folks work in pairs and this was not made available to the online program, despite the on campus program likely being the same remote learning due to the pandemic.

There were not very many systems for support in this class to help people be successful. The first few labs set you up to believe the work will be moderate but then the last two projects will consume all your free time and energy. If you are fine with that then proceed but you are being warned here that you won’t have time for anything else in your life for about two months. In addition to that, the labs are brutal. Averages on project 4 and 5 were in the 50’s and most students did not complete them after weeks of nonstop effort.

As far as the good things, the professor is really engaged and responsive and cares. The material is very interesting and knowing fundamentals of distributed systems is a rite of passage and a necessary one these days. However, I think this class has a lot of room for improvement to help students learn in a more rewarding and healthy environment. More TA’s and support, along with opportunities for collaboration, and better pacing and structure and communication would go a long way.

All that being said, I’d reach out to the professor and just see if things have changed or improved since this initial semester and go with however you feel from that reassurance. But this class as it stands was brutal and I wouldn’t recommend this current form to anyone.

Overall I enjoyed this class. This is my 8/9th OMCSC course and is by far the one that requires the most effort. The lectures are well presented. The exam is pretty straight forward. The projects are brutal but I did learn a lot. I probably spent more than 100 hours on each of project 4 and project 5, and my work/life/study balance really suffered because of that. I can't remember the last time I cooked or did anything relaxing. Lots or people in the class had to take personal days off to finish the projects or get a decent score (the mean/median of project 4 was below 60, as a reference).

If you do decide to take this class I would recommend start as early as you can on the later projects (project 3 onwards). Usually people just don't have 100 hours in a week to focus on projects, so it's best to start as early as you can and spread it out a little bit. Also get the debugging process running as smoothly as possible in the first few projects when time pressure is low. Make sure you know how to log, and how to tune the granularity of logging at runtime. Good luck and have fun!

Projects are involved, especially for the last 2. Great for experienced engineer. This is not a toy project. This is one of the most challenge class projects I have ever done.

I do learn a lot and met some genius class mates.

Seriously. Just avoid this class. There are no rules and no one is benefitting.

Honestly I would have rather gone an extra semester in the program than stay in this class for two months beyond the drop date

I am tired of hearing “you learned this in 6200”. If 6200 is required then make it a formal prerequisite. Otherwise, don’t assume everyone in a class has taken an arbitrary course before this one. It only makes for a more confusing experience. Not only do the lectures have this concept of needing to know prior course information, but the projects themselves are heavily dependent on knowing information from another course, which is not a prerequisite. P5 apparently requires a deadlock prevention mechanism that was learned in 6200 but I assume not everyone in the course took that class so this is just embarrassing to require without any explanation whatsoever. I have had enough of this class and I would honestly just stay the hell away from it for the immediate future if you have any desire to maintain sanity and health.

I just feel burned out and dead inside. I look at the final project and I don’t have any gas in the tank to deal with this BS anymore. I went through all stages of grief with this nightmare fuel of a course and in three weeks it will finally be over after 4 months of the most misery I have had in a long time. The original course let people pair up and there is NOTHING stopping them from doing this in the online version. This is crucial. You want someone to bounce ideas off of and work on these labs with and being told by TA’s that these are easy when they had a clear advantage we don’t have is utter nonsense. There are no office hours for actually getting help and I think it’s just a hot mess. I hope people fill out the course surveys and also I hope the curve is forgiving because this is a disaster all up.

This class is for experienced engineers, not students (unless you have a specialised masters or PhD in this subject already)

The concepts taught are medium-hard to understand, the coding difficulty is reasonable, but the dslabs tests and the ambiguous project descriptions means you will keep refactoring this till you either hate your life, know your stuff well or get lucky and make stuff pass - though even then you will still likely be far away from having an efficient & reliable design (e.g. production-level).

Teaching quality: bad, the help we get is very limited and slow (and worse, sometimes patronising). You are on your own to figure out the many undocumented tests to understand what protocol/design you should be implementing. Remember, you are not in this class to be taught anything, you are here only to be assessed, so you would better know most of this stuff or similar already (or alternatively, be very comfortable with extreme challenges).

Projects relevance: good in terms of concepts covered and quite useful if one wants to learn about distributed systems.

Exams relevance: the lecture material is sadly very short and we are instead referred to 15-20 research papers per mid-term and similar for final exam. These papers are hard to digest and to properly understand them without prior experience of DS stuff, it can take many months. The disappointing part is that I've learned nothing from the lectures or the exam material due to the way this course is taught.

Workload: seems to be more manageable for people already working on DS or similar in the industry (a few are the arrogant type taking the wrong kind of pride on how easy this is for them, but most of the class is struggling and is pretty much tortured trying to learn everything from scratch on their own under extreme deadlines).

Time pressure: extremely high if you are not comfortable with this stuff ( means it's likely you'll experience the steepest learning curve in any OMSCS course). Most of the time is spent on debugging rather than coding, it can get frustrating very fast if you encounter long/complex execution patterns.

Overall: I wouldn't repeat this nightmarish 4 months experience if given the option again. There are plenty of other ways to learn about distributed systems without sacrificing your health, your job, your life... and without having to deal with smartas... on top of everything

I don't usually post reviews until I finish a class, but thought I'd try to counter balance the negative reviews for those interested in taking this class in Fall.

dslabs

The crux of what makes this class difficult is dslabs. dslabs was created in 2019 to provide a rigorous, search based framework for teaching distributed systems implementation at University of Washington by Ellis Michael. He published a now well known paper (https://ellismichael.com/papers/dslabs-eurosys19.pdf), which has gained a lot of traction in the systems world, and many top university programs are moving to using dslabs for their distributed systems course.

Why has it gained traction? Well, building and teaching distributed systems is notoriously difficult. Distributed consensus is one of the most difficult problems in all of computer science. Paxos remained in obscurity for the beginning of its life, despite being the most important consensus algorithm published, because people simply couldn't understand it. Teachers have struggled for a long time to try and get their students to understand the difficulties and intricacies of implementing something like Paxos.

So when dslabs came out, we finally got a framework for teaching that would actually push students to deal with all the difficulties and edge cases of building a distributed system. It has some of the most thorough tests of a Paxos based distributed system of any open source project. If you can implement dslabs, you will have a real, pragmatic understanding of how to implement multi paxos, and any of its derivatives (Raft, etc.).

course pains

Okay, enough about dslabs. There are some issues with the course itself right now which makes it more difficult than it should be.

The pacing of the course is way off currently. We were only given effectively 2 weeks to implement the paxos lab 4 (dslabs 3), which was INSANE and broke many of the students now posting negative reviews. It nearly broke me. I spent 80-100 hours on this lab in the course of 2 weeks which is just crazy, and affected my health. This isn't necessarily dslabs fault, this is just an issue with how the course timing was set. The professor is aware of it though, and I imagine the next iteration will get more time to complete these labs.

There also just wasn't enough support for the labs. dslabs is really, really hard. You can't expect students to just figure it out themselves. The initial offering of this class should have been much smaller, because only 1 TA understands the labs (I assume he wrote the class reference implementation). These labs need one on one support, and lots of help, so people can understand and complete them.

The lectures are good in my opinion, Professor Ada has done a good job covering the various topics, and the papers are interesting too. But they barely register, given 99% of your time is spent on the labs.

The exams so far have been easy, I think in recognition of the difficulty of the labs.

conclusion / advice

I was waiting for distributed systems to be offered online for a long time, and I'm nearly done my degree. I'm happy this course was offered before I graduated, and I'm also happy about the project rigor since I am learning so much. But the class needs some fundamental restructuring to better support students, and the pacing needs to be fixed. Lab 4 pushed me to the limit and I never really had an experience like that before, even working in crunch environments professionally.

If you want to get a head start, you can start implementing dslabs yourself - it's on github. Expect to spend 200-300 hours to complete it all. Although there's a good chance you'll get stuck and be unable to make progress without help! But at least you'll be ahead of the game. Good luck to those taking this in Fall!

The content is very good, but projects 4 and 5 are just insane. You don't have to be a great engineer to solve 4 and 5, but rather you just need to be lucky. These projects are different than other projects in the OMSCS program because tests are NOT deterministic, don't fully test a feature, and projects are poorly written. This makes it extremely easy to forget or misunderstand an edge case, and it can cause everything to crumble at the end. You can spend hours/days trying to reproduce a bug, and after you find it realize the rest of your project is wrong because it was built off this bug passing 99/100 times.

The TAs are helpful, but they have limited time because of the large amount of questions. They don't have individual office hours, and you obviously can't meet with them 1 on 1.

The in person version of this class has partners, and I'm unsure why they chose not to allow this in the online version. It's critical to have another person if you can't have all your questions answered by TA. A partner would ensure you both understand a project, and would help reason about every edge case.

I would say email the professor and ask whether significant changes have been made to this course since Spring 2021 for OMSCS and if the answer is not reassuring then stay the actual hell away from this class. The TA's are a passive aggressive set of people who will make you feel like an idiot for asking a question on the question thread. While we are talking about the thread, there are no actual office hours or ways to get help in this course. They make an FAQ post on Piazza where everyone just posts endless questions and get vague and passive answers until you give up trying to get help. Then you might get someone who sneaks in through the cracks and gets a helpful answer but you would have to find the straw of hay in a pile of needles to get that answer since the thread will likely be a couple hundred posts deep. It's just a hot mess.

The projects are death. You basically get no instructions at all. Just a overly wordy description of the goal and buzzwords like "Load balanced shard" and then are told the solution is 500 lines of code. You can't discuss code with other students so you just kind of go insane after a while. Students try to find loopholes by talking about the design but honestly its a mess. If this was on campus we would be working in pairs but in OMSCS we cannot even work together with anyone. I guarantee you on campus students were meeting in the library and looking at each other's code and helping each other out. This is not a BAD THING. This is how literally all software problems are solved in the real world via asking questions and getting help from your peers, but I digress.

The labs are skewed to be weighed more for the hardest unit tests which are like if a panic attack and a paranoia episode had a baby. You can have a really good working solution and fail the lab because you did not pass arbitrary tests at the end which do not teach you anything AT ALL about what you are making. Its effectively like if you made a good application and then your QA team ran a scripted that messed it all up with arbitrary issues and then you got fired for that. You know what you made and you learned something but are being punished because its not the God-mode of Paxos, which is funny since this is a class where we are supposedly learning these things for the first time LOL

Yeah right. You don't learn anything in this class except how to get really clever about breakpoints and print statements and pushing your mental health to the absolute bring. I have discussed this class with my therapist a handful of times and its just a hot mess. I would have the stamina to keep going in the last month but I am so burned out I can barely function.

Seriously. Ask the professor if things are better than Spring 2021 and if not then just stay the hell away and read a distributed systems book or just ask for the papers we go over and read those and try to code up these things without being under the absolute GAUNTLET of DSLabs.

The labs are open source and public btw so you could theoretically just do them before you take the course but then also they may make changes to the course which make it not 1:1 and I would not recommend the misery of these labs unless it was 100% what you were going to be doing in the class.

Best of luck and I hope everyone in this class still this semester is doing ok. We are almost done.

Super fun course, super fun project, unfortunately with a very high workload.

The course is currently on project 3 (5 in total), for P3, 2/3 of the class have spent 50hr+, and yet still unfinished. It is not uncommon to refactor everything, for a couple of times, by the time one reaches the last 2 tests.

I'll probably drop. No regret though. I've committed all my spare time (after work) and it still didn't seem to be enough :-/. hope to continue in summer