Picture an online store whose orders database runs on one Postgres machine. Every order, every product-page read, and every address change lands on that single node. That works until one of three things happens: reads outgrow the machine, the machine dies and takes the only copy with it, or customers on another continent wait on a round trip across an ocean.

Database replication is the answer to all three. You keep copies of the same data on several nodes, so reads can spread out, a copy survives a node's loss, and data can sit near users.

Every extra copy raises the same question: which copy is right? A copy can be a few hundred milliseconds behind. Two copies can accept different writes to the same row. The copy you promote after a crash can be missing orders the old leader already confirmed. Choosing a replication design means accounting for these risks as well as the extra read capacity and durability.

In interviews, replication rarely is the main question, but it shows up in almost every deep dive once your design has a database: "what if this node dies?" and "how do reads scale?"

A few minutes of crisp reasoning usually satisfies. At mid-level, the bar is a leader with replicas, what lag looks like to a user, and how to route reads around it. Senior candidates are also expected to explain write conflicts and what a failover does to acknowledged writes.