Replication Basics And Interview Framing

Replication is keeping copies of the same data on more than one machine, so the service can keep working when one machine fails and so it can handle more traffic than a single machine can.

To make that concrete, we will use a simple user profile service that supports GET /profile/{user_id} and PUT /profile/{user_id} to read and update a user’s name, photo URL, and settings.

One server is enough until the profile database becomes the single point of failure and the single throughput ceiling, because every read and write depends on that one machine being healthy and fast.

The next view fixes our baseline in place so later lessons can stress it and watch where it breaks.

In that baseline, clients call the API service, and the API service reads and writes a single database, so a database crash stops both reads and writes and a traffic spike piles up on one CPU and one disk.

That is the pressure that makes replication a design topic in interviews, because the interviewer will push on what happens during failures and what happens under load, not on how an endpoint is implemented.

Requirements that drive replication choices

Replication is not a single feature. It is a set of choices that depend on what the system must guarantee when parts fail.

For a profile service, the interviewer usually starts by testing whether we can ask for the few requirements that change the replication pattern, before naming any specific technology.

The knobs to clarify map directly onto the read and write flows.

• Availability target, such as whether reads must succeed during a node outage.
• Read to write mix, since heavy reads benefit from replicas differently than heavy writes.
• Acceptable staleness, meaning how old a read is allowed to be.
• Failure domain, meaning whether we design for a machine failure, a zone outage, or a whole region loss.

Once those are stated, replication stops being an abstract idea and becomes a concrete contract, such as whether GET /profile is allowed to return an older photo for a few seconds after PUT /profile succeeds.

The smallest replicated baseline

With requirements framed, the smallest replicated design adds exactly one more database copy and decides how updates move between them.

We keep application semantics unchanged for now. Clients still talk to one API tier, and the API tier still issues one logical write that should not silently split into conflicting versions.