Design a synchronously replicated hash map
PremiumDistributed infrastructureMedium
- Synchronous replication
- Active passive failover
- Fencing epochs
Quick answer
This distributed infrastructure interview question asks you to design a synchronously replicated hash map. Aim for a design that keeps working across many machines and failures, then explain partitioning, replication, coordination and trade-offs. Interviewers want to see how you reason about failures, consistency and scale.
The problem
Design a synchronously replicated hash map with one active node and one passive backup, where every write is copied to the backup before it is acknowledged, or rejected. It resembles the primary-backup core of an in-memory database. The hard parts are lost and repeated messages, nodes restarting with old data, and never having two active writers after failover.
Clients send GET, PUT, DELETE and compare-and-set (CAS) requests to the active node. The active sends each write to the backup and acknowledges the client only after the backup has stored it. If the backup cannot be reached, the write is rejected instead of being accepted on one node. A third warm spare node is available to become the new backup.
What must a synchronously replicated hash map do?
- Synchronous writes: PUT, DELETE and CAS are acknowledged only after the backup has stored them; otherwise the client gets an error and the write has no effect.
- Single active: At most one node accepts writes at any time, including during and after failover.
How well must it do it?
- No lost writes: An acknowledged write survives the failure of either node.
- No split brain: Two nodes never both accept writes, even during a network split.
What scale should you design for?
Use these numbers in your estimates.
The scale numbers unlock with this questionUnlock
Key concepts
- Synchronous replication
- Active passive failover
- Fencing epochs
- Sequence numbers
- Leases
- Idempotent writes
How you’ll practise
- Requirements
- Estimate
- Data model and API
- Partitioning and replication
- Consistency and failures
- Wrap-up
Lala, personalized to you, gives a hint when you ask and reviews your design when you are ready.
What do interviewers look for?
In any distributed infrastructure design round.
- States the consistency and availability guarantees up front
- Explains partitioning and replication choices
- Describes how nodes agree and recover after failures
- Handles network partitions and slow nodes
- Plans for adding and removing capacity safely
- Names the trade-offs instead of hiding them
Questions people ask about this interview question
- Which design type is this question?
- It is a distributed infrastructure question. You design a synchronously replicated hash map and explain your choices the way you would in an interview.
- Is this question asked at entry level?
- It is marked Medium. Entry-level engineers can practise it, but it expects you to reason about requirements and trade-offs, not only list components.
- What should I cover first?
- Start with the guarantees the system must give and the failures it must survive. Agree on scope with the interviewer before you design anything.
- Can I practise it for free?
- It is a premium question. Sign up and unlock it once for 10 credits; it then stays unlocked. When you finish, Lala, your personalized AI mentor, can review your design for 30 credits.
Related questions
Updated · Written by the SevyDevy team