I worked at the same company for about ten years. While I ended up working on many different systems, there were a couple constants in the mix. It’s remarkable how ingrained those codebases are in my head. Having started a new job, I miss the ability to quickly know exactly where in the code needs to change to support some new feature.

This ability to navigate a codebase in your head feels to me very much like navigating the physical world. It feels almost like walking through callgraphs and directory structures. In a codebase I’m very familiar with, I can plop myself down to exactly the right location and all paths from there are clear. In a new codebase, I often need to start from some few currently-known starting points and try to navigate from there, trying to discover my destination. I wonder if it’s the same for others.¹

A well known pattern for building systems is to break them down into data planes and control planes. Despite having known this and done this for years, I never considered this distinction within log replication protocols, another thing I’ve thought about for years. The data plane of a log replication protocol can just be concerned with failure-free data redundancy (e.g. replication or erasure coding). The control plane is then concerned with handling and recovering from failures. Raft is a ‘converged’ protocol mixing both data plane and control plane is one protocol and one log. But it doesn’t have to be that way.

I think this is a nice framework to think about the variety of log replication prtocols out there. Thanks to Jack Vanlightly for writing about this. Check out his survey on the topic.