Design a Synchronously Replicated Hash Map

# Design a Synchronously Replicated Hash Map Design a hash map with one writer, one reader, one active replica, and one passive replica. A write must be replicated synchronously or fail. Explain the write protocol, read semantics, failure handling, recovery, and how the design prevents two writers after failover. ### Constraints & Assumptions - Network messages can be delayed, duplicated, or lost. - Either replica can restart with stale durable state. - A timed-out client may not know whether a write committed. ### Clarifying Questions to Ask - Must reads be linearizable, and which replica serves them? - What durability and failover-time objectives apply? - Is an external consensus or lease service available for leadership and fencing? ```hint Define the commit point The response to the writer is safe only after the required replicas agree on an ordered durable write and its leadership epoch. ``` ### What a Strong Answer Covers - Ordered log or versioned writes and synchronous acknowledgment. - Idempotency, ambiguous timeout handling, and read consistency. - Leader election or leases with fencing against stale writers. - Snapshot/log recovery, observability, and availability trade-offs. ### Follow-up Questions - Can the system remain writable when the passive replica is unavailable? - How would you add a second reader without weakening consistency?