Lab 3 Design Doc

Intro

• We have presented an overview of the multi-paxos protocol we want you to design in lab 3.
• We have intentionally left out many details! These are for you to design and fill in.
  • 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!

Instructions

• 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 as any typeset PDF on gradescope.
    • The text can be a google doc, word doc, latex, typest, pandoc, or other. Both typst and overleaf (latex) offer free online editing.
    • Diagrams can be in any readable form, including hand sketched (if hand-sketched, scan into an image on your phone, and then include that image in the pdf). However, we recommend the free website draw.io
  • Be sure these sections appear explicitly with exactly these titles in large font in your doc. The rubric grades each section separately. You will need to mark each section explicitly in Gradescope.
    • Preface
    • Protocol
    • Correctness/Liveness Analysis
    • Conclusion
  • 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 design decisions".
  • You should be specific about state, messages, timers. We were not specific in lecture.
  • 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.

Advice

Here is some advice based on things we noticed from winter quarter design docs.

• 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 question.
• 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 less.)
• 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.