Paxos — Part 3: System Design & Interview Mastery

maang.io System Design Series

What is this?

You now know Paxos from the acceptor's two variables up to Multi-Paxos's replicated log. This chapter is where that pays off in a room. Interviewers almost never ask you to recite the protocol — they ask you to recognize when a design needs consensus, reach for it (or deliberately avoid it), and defend the cost when they push back. The senior signal isn't "I can describe Prepare and Accept." It's "I know that consensus is expensive, I use it only where a system genuinely needs one agreed truth, and I can tell you exactly what it buys and what it costs."

We'll do two things: see where Paxos fits in real designs (with diagrams), then run a mock interview — for each question, what they're really asking, a model answer, and the senior line that signals you've built this for real.

The one-line idea: interviewers use Paxos to test whether you can tell "we need everyone to agree on one thing" (consensus — Paxos/Raft) apart from "we need this to always be writable" (availability — quorum replication/gossip) apart from "we need these separate parties to commit together" (atomicity — 2PC). Naming which problem you're in is the whole game.

Our six friends and their dinner vote come along one last time — because "the group must agree on exactly one plan, and survive some phones dying" is precisely the shape that should make Paxos light up in your head.