How does database replication affect design?

Direct answer

What a strong answer covers

How it works

Replication copies changes from a primary to one or more replicas, which gives read capacity, a standby for failover, and copies in other regions. Asynchronous replication means replicas lag, so a read after a write may not see the write; synchronous replication removes that lag for the acknowledged replica at the cost of write latency and availability if the replica is down. Design decisions follow: which reads can tolerate staleness and go to replicas, which must read the primary or use read-your-writes routing, how the application discovers the new primary after failover and retries in-flight transactions, and how lag and replication health are monitored so a silent break is caught before a failover to stale data.

Example

An e-commerce platform routes product browsing to replicas and everything inside checkout to the primary; after a user updates their address, the session is pinned to the primary for 10 seconds so the confirmation page reflects it. Failover is automated with a virtual endpoint, the connection pool discards connections on the primary change, and an alert fires when replica lag exceeds 5 seconds, which once revealed a replica that had silently stopped applying changes.

Common mistakes

• Sending every read to replicas and showing users their own writes as missing.
• Assuming failover is instant and not handling the seconds of write failures during it.
• Ignoring replication lag until a failover promotes a replica minutes behind.

A useful answer structure

Answer from your own work.

Do not memorise a script: use only examples you can explain honestly in follow-up questions.