Where replication fits on a long engagement.

Replica lag is the thing applications get wrong. A write to the primary followed immediately by a read from a replica may not see it, which produces the classic defect where a user saves something and it appears not to have saved. The application has to decide, per read, whether it can tolerate slightly stale data.

Failover is the other half and is frequently untested. Promoting a replica involves the promotion itself, redirecting applications, and handling any writes the old primary accepted but did not replicate. A failover procedure that has never been exercised is a plan, not a capability.

What an assigned team does with replication.

Replication is usually introduced for read scaling and then quietly relied on for availability, without the failover work that assumption requires. The gap is discovered during the incident it was supposed to protect against.

Testing failover deliberately is ordinary operational rigour, held by the assigned capacity as part of the standards described in how an assignment runs.

What we use replication for.

  • Read load moved off the primary Reporting and analytics served from replicas, with staleness tolerance decided per read.
  • Failover that has been exercised Promotion tested, so availability is a capability rather than an assumption.
  • Lag monitored and acted on Replica delay alerted, because a lagging replica silently serves old data.

How replication capacity is assigned.

Replication work is assigned under managed data services, with failover tested rather than documented.

Tell us what your roadmap needs replication for.

A service delivery manager replies with the disciplines we would assign, the monthly capacity and what the first month looks like.

Loading the contact form… You can also email hello@azendo.co.

We reply within one working day. No obligation, and no newsletter.