Read Replicas Strategy

Use; offload; replication lag.

Overview

Read replicas scale reads horizontally by accepting that some queries can tolerate slightly stale data. The catch is replication lag: replicas are eventually consistent with the primary, lag is usually milliseconds but spikes during high write load, and reading a replica immediately after writing to the primary returns the pre-write state. The discipline is matching each query to the consistency it actually needs and routing accordingly, with explicit fallback for the queries that cannot tolerate lag.

• Read offload. Per-query routing to replica; offloads the primary, scales read throughput linearly with replica count.
• Replication lag awareness. Per-query lag tolerance; pages that show your own profile are read-after-write, pages that show aggregate data are not.
• Read-after-write fallback. Per-write subsequent reads route to primary for a short window; the user sees their own write reflected.
• Per-replica routing plus lag monitoring. Per-query the right replica based on lag; per-replica lag monitored continuously to catch divergence.

The approach

The practical approach is per-query routing decisions made at the application layer, lag-aware routing that excludes lagging replicas from the rotation, read-after-write fallback for the user-affecting subset, per-replica lag monitoring that alerts when lag exceeds tolerance, and a documented per-database routing strategy committed to the repo so the model is reviewable.

• Read offload. Per-query the read replica when consistency tolerance allows; the primary stays for writes and read-after-write reads.
• Lag-aware routing. Replicas above lag threshold get pulled from the rotation automatically; user-facing reads do not see stale data when replicas are unhealthy.
• Read-after-write fallback. Per-write subsequent user reads route to primary for a short window (typically 1-5 seconds); the user sees their own write.
• Per-replica monitoring plus documented strategy. Per-replica lag monitored continuously; per-database routing strategy committed to the repo for operational review.

Why this compounds

Read replica discipline compounds across queries and quarters. Each correctly-routed read offloads the primary; the read tier scales linearly with replica count; user-visible correctness stays intact because the routing respects per-query consistency requirements. After a year, the team has a vocabulary for read-write routing that pays off on every new feature.

• Read scale. Right read offload supports throughput; the primary handles writes and the replica tier handles bulk reads.
• Correctness. Right routing matches consistency requirements; users see their own writes immediately, see other users’ writes within the lag window.
• Operational fit. Right replicas match workload; lag-aware routing prevents stale-data incidents during write spikes.
• Institutional knowledge. Each routing decision teaches consistency patterns; the team learns when stale-tolerant beats fresh-required.

Read replica discipline is a database discipline that pays off across years. Nova AI Ops integrates with database telemetry, surfaces lag patterns, and supports the team’s read-routing discipline.