||March 23 23:59|
|Code and write-up due:
||May 11 23:59|
You can either do a final project based on your own ideas, or Lab 4.
If you want to do a project,
you must get our approval for your idea in advance.
You must form a group of 2 or 3 6.824 students to collaborate on the project.
You'll turn in your code and a short write-up
describing the design and implementation of your project, and make
a short in-class presentation about your work. We will post your write-up
on the course web site unless you
talk to us about why you want to keep it confidential.
Your project should be something interesting and challenging that's
closely related to 6.824 core topics, such as fault tolerance.
The project must involve at least as much effort as Lab 4.
you'll find some half-baked ideas that we think could turn into
interesting projects, but we haven't given them too much thought.
There are four concrete steps to the final project, as follows:
Form a group and decide on the project you would like to work on.
Feel free to use Piazza to find group members and discuss ideas.
Course staff will be happy to discuss project ideas via e-mail or in
Flesh out the exact problem you
will be addressing and how you will go about solving it.
By the proposal deadline, you must
submit a proposal (less than a page) describing: your group members
list, the problem you want to address, how you plan to address it,
and what are you proposing to specifically design and implement.
Submit your proposal to
We'll tell you whether we approve, or not, and give you feedback.
Execute your project: design and build something neat!
Write a document describing the design and implementation of your project,
and turn it in along with your project's code by the final deadline.
The document should be about 3 pages of text that helps us understand what
problem you solved, and what your code does. You can either send the code to
the staff list or provide a link to an repository (e.g., on GitHub) in your
writeup. The code and writeups will be posted online after the end of the
Prepare a short in-class presentation about the work that you have
done for your final project. We will provide a projector that you can use to
demonstrate your project.
Half-baked project ideas
Here's a list of ideas to get you started thinking -- but you should
feel free to propose your own ideas.
- Re-implement any of the systems described in the papers that 6.824 lectured on.
- Build a distributed, decentralized, fault-tolerant Reddit.
- Make the state synchronization protocol (DDP) in Meteor more efficient (e.g., send
fewer bytes between server and client) and more fault-tolerant (e.g.,
a client should be able to tolerate server failures, as long as enough
servers remain live).
- Build a system for making Node.js applications fault-tolerant,
perhaps using some form of replicated execution.
Zephyr client by replicating the backend to make it fault-tolerant.
- Add cross-shard atomic transactions to Lab 4, using two-phase commit
- Build a system with asynchronous replication (like Dynamo or
Ficus or Bayou). Perhaps add stronger consistency (as in COPS
or Walter or Lynx).
- Build a file synchronizer (like
- Build a coherent caching system for use by web sites (a bit
like memcached), perhaps along the lines of
- Build a distributed cooperative web cache, perhaps along
the lines of
- Build a collaborative editor like EtherPad, using
eventually-consistent or CRDT primitives.
- Build something useful around a blockchain.
- Add one of the following features to
eventually-consistent research data-flow system (with some similarities to
- Transactions with two-phase commit across different base tables.
- Client-side data-flow operators and stateful caches.
- Replication for individual data-flow operators or the whole data-flow.
- Rollback recovery from failures similar to this proposal.