Measure and understand replication lag
Use the database’s replication metrics or logs to observe lag and whether it is measured by time, log position, or another engine-specific value. Look for sustained increases and correlate them with write volume, long transactions, or resource pressure.
For a user who just changed data, use the primary for the follow-up read or wait until the replica has applied the relevant commit position if the database exposes that capability. Keep ordinary reads on replicas when eventual consistency is acceptable.
Set an explicit consistency policy
Document which screens, workflows, or jobs need read-after-write behavior and which can tolerate delay. Avoid adding arbitrary sleeps; they increase latency without proving that replication has caught up.
Alert on lag that exceeds the application’s tolerance and provide a fallback path. Test behavior during replica restart, catch-up, and failover so stale reads do not silently drive destructive actions.