Returning Reads to Replicas After Consistency Is Satisfied


𝗪𝗵𝗲𝗻 𝗖𝗮𝗻 𝗬𝗼𝘂 𝗦𝘁𝗼𝗽 𝗥𝗼𝘂𝘁𝗶𝗻𝗴 𝗥𝗲𝗮𝗱𝘀 𝘁𝗼 𝗧𝗵𝗲 𝗣𝗿𝗶𝗺𝗮𝗿𝘆?

A user updates their profile.

The write succeeds on the primary. For the next few reads, the application keeps using the primary.

But when should reads move back to replicas?

𝗡𝗼𝘁 𝗯𝗲𝗰𝗮𝘂𝘀𝗲 𝗮 𝘁𝗶𝗺𝗲𝗿 𝗲𝘅𝗽𝗶𝗿𝗲𝗱.

𝗕𝗲𝗰𝗮𝘂𝘀𝗲 𝘁𝗵𝗲 𝗿𝗲𝗾𝘂𝗶𝗿𝗲𝗱 𝗰𝗼𝗻𝘀𝗶𝘀𝘁𝗲𝗻𝗰𝘆 𝘀𝘁𝗮𝘁𝗲 𝗵𝗮𝘀 𝗯𝗲𝗲𝗻 𝗿𝗲𝗮𝗰𝗵𝗲𝗱.

💡 𝗘𝘅𝗮𝗺𝗽𝗹𝗲

Required position = 5000

Replica A = 4970 → ❌ Not eligible
Replica B = 5000 → ✅ Eligible

The router can now switch:

𝗣𝗿𝗶𝗺𝗮𝗿𝘆 → 𝗥𝗲𝗽𝗹𝗶𝗰𝗮

The key check is conceptually:

𝗥𝗲𝗽𝗹𝗶𝗰𝗮 𝗽𝗿𝗼𝗴𝗿𝗲𝘀𝘀 >= 𝗿𝗲𝗾𝘂𝗶𝗿𝗲𝗱 𝗽𝗼𝗶𝗻𝘁

You don't need to wait for every replica. If one replica has caught up and satisfies the consistency requirement, it may be eligible for reads.

⚠️ 𝗖𝗼𝗺𝗺𝗼𝗻 𝗠𝗶𝘀𝘁𝗮𝗸𝗲

“Primary for 5 seconds, then replicas.”

If replication catches up in 50ms, you're wasting primary capacity.

If replication takes 10 seconds, switching after 5 seconds can return stale data.

🎯 𝗧𝗮𝗸𝗲𝗮𝘄𝗮𝘆

𝗣𝗿𝗶𝗺𝗮𝗿𝘆 𝘂𝗻𝘁𝗶𝗹 𝗰𝗼𝗻𝘀𝗶𝘀𝘁𝗲𝗻𝗰𝘆 𝗶𝘀 𝘀𝗮𝘁𝗶𝘀𝗳𝗶𝗲𝗱 → 𝗥𝗲𝗽𝗹𝗶𝗰𝗮 𝘄𝗵𝗲𝗻 𝗲𝗹𝗶𝗴𝗶𝗯𝗹𝗲.

And once the requirement is satisfied, clear or expire the sticky primary-routing state.

𝗛𝗼𝘄 𝘄𝗼𝘂𝗹𝗱 𝘆𝗼𝘂 𝗶𝗺𝗽𝗹𝗲𝗺𝗲𝗻𝘁 𝘁𝗵𝗶𝘀 𝘁𝗿𝗮𝗻𝘀𝗶𝘁𝗶𝗼𝗻?

Would you use LSN, GTID, replication position, commit timestamp, or something else?

💬 Share your approach in the comments.

#DistributedSystems #SystemDesign #DatabaseReplication #Databases #BackendEngineering #ReadReplicas #Scalability #SoftwareArchitecture #SoftwareEngineering

Previous Post Next Post