Update: This version of my paper is superceded by a new version: 4 modifications to Raft consensus. Please read it instead.

August is usually a slower month as a lot of people are on vacations. I try to take advantage of that to work on tasks that require a bit more deliberation and quiet time. This Summer I returned to re-reading the paper on the Raft algorithm, in particular my colleagues in New York pointed out that the PhD thesis that extends on the original paper was now complete, and contains some additional details.

Spencer Brody from the MongoDB engineering team gave a talk on Raft and MongoDB at MongoDB World in June. If you want to learn more about how Raft will translate into MongoDB, you should watch it, it is a great reasource. In this paper I have focused solely on addressing some corner cases in the context of Raft itself.

While Raft is great, you can always do more to be perfect. At this point I have quite some experience with various database replication technologies, so I could immediately spot some features missing that I've found to be useful properties of a database replication solution.

Now that I publish this paper on my blog, it has not yet been reviewed by anybody else than myself. I welcome any comments or even corrections, should you find any. (Comment box below is fine, or my email at henrik.ingo [at] openlife.cc)

Paper: Three modifications for Raft consensus (PDF)

Btw, for those that don't know me, I'm not actually on the MongoDB dev team, I'm just a solutions architect who has to live with this technology with customers. So that's motivation enough to try and help make it as good as possible! And, to have something fun to do while customers are on vacation :-)