Lab 3 Design Doc
- We have presented an overview of the kind of MultiPaxos protocol we want
you to design in lab 3.
- We have intentionally left out many details! These are for you to design and
- There are many different ways to get a correct protocol. There is not just
one right answer.
- The act of taking high level ideas and turning them into concrete distributed
protocols that can be implemented, evaluated, and deployed is a core skill
that we hope you develop in this course!
Generic instructions for design docs
- You will write a design doc (with your partner, if applicable) for lab 3 based
on the high-level description from lecture.
- Follow the template.
- You can submit your design doc in any readable format as a PDF on gradescope.
- Handwritten is fine, so is plain text ascii, word doc, \(\LaTeX\), or anything else.
- Be sure these sections appear explicitly with exactly these titles in large font in your doc
- Besides those section titles, you do not have to follow the rest of
the template exactly, but you must include the spirit of all the
information requested in the template in some format.
- Feel free to include diagrams or informal discussion wherever you see fit.
- Your design doc should fill in all missing details that are "distributed
- You should be specific about state, messages, timers. We were not specific
- Try to avoid low-level Java-specific details where possible. Your document
should make sense in any programming language.
- Be sure to incorporate any relevant feedback you got on your lab 2 design doc.
New in lab 3
Here is some advice based on things we noticed in the lab 2 design docs.
- For lab 3, you can omit the Invariants/Stable Properties and
Performance sections from Analysis.
- Do not repeat yourself. Do not copy paste. Instead, you can say "it
is similar to blah", where "blah" directs the reader to the relevant
part of the document.
- Structure your design doc so that it is readable. When answering
several questions from the template about a single variable, group
all the answers about one variable together, do not group answers by
- Try to keep your design doc to be less than 15 pages. (This is a
soft requirement, not a hard requirement. You will not lose points
for writing more. You will definitely not lose points for writing
- The most important section is the protocol section. That is the
section you will translate into Java. Be extremely specific about
exactly what data each node stores, what data is on each
message/timer, and how a node's state changes when a message/timer
is delivered/fired. "Extremely specific" does not mean "long
winded". Be precise but concise.
- Memes are good. Include memes. Memes about Paxos. Memes about design
docs. All memes are good.