Layer 3 · Go deeper · 9 min
Go deeper
Size it, build it, then make the calls an interviewer will push you on.
Back of the envelope
Size it up
Tap through each step of the arithmetic.
What does a Frankfurt user pay to read from Mumbai?
How many acknowledged writes can one async failover lose?
Build-up · 5 steps
Three moments a commit can say “OK”
The primary has the write. When it replies to the app sets your write latency and how much a failover can lose.
Step 1 of 5
Async: OK after the local flush
The primary flushes its WAL and replies at once. It is the fastest commit and a slow follower never slows it, but if the primary dies before shipping, the acknowledged write is gone.
4 interview moments
You’re the candidate
The interviewer pushes on the hard parts. Pick an approach and see how it holds up.
Deep dive 1 of 4
Interviewer
“Payments run on one leader with two followers in other zones. When should a commit tell the app “OK”?”
Your move. Pick an approach:
Deep dive 2 of 4
Interviewer
“A customer saves a new address. The reload reads a replica two seconds behind and shows the old one. What do you change?”
Your move. Pick an approach:
Deep dive 3 of 4
Interviewer
“Replicas must stay exact through UPDATE orders SET token = UUID(), and change data capture tools will read the log. What do you ship?”
Your move. Pick an approach:
Deep dive 4 of 4
Interviewer
“Your MySQL primaries are on the East Coast with async replicas on the West. Should failover across regions be automatic?”
Your move. Pick an approach:
Build-up · 5 steps
Fail over an async leader
Every failover detects, elects and reconfigures. Follow one with asynchronous replication and watch where the acknowledged writes go.
Step 1 of 5
Acked on the leader only
Node A acknowledges w1 to w5 to clients and ships its log afterwards. Node B runs half a second behind, so it holds only w1 to w3.