---
title: "Comment by Kamran Khan on \"System Design Drill Day 4: Read Replicas and Replication Lag\" | Hashnode"
description: "One caution on the session-based pin: keep it narrow. Pinning every read for a few seconds after any write sends the whole dashboard to the primary, including t"
url: "https://hashnode.com/posts/system-design-drill-day-4-read-replicas-and-replication-lag/6ad97f46fe6584e965eff0fc/comment/6ada0d116bed55b873dade9e"
---

[Discussion](https://hashnode.com/posts/system-design-drill-day-4-read-replicas-and-replication-lag/6ad97f46fe6584e965eff0fc)

Comment [System Design Drill Day 4: Read Replicas and Replication Lag](https://hashnode.com/posts/system-design-drill-day-4-read-replicas-and-replication-lag/6ad97f46fe6584e965eff0fc)

[Kamran Khan](https://hashnode.com/@kamrankhandev)

[Oct 22](https://hashnode.com/posts/system-design-drill-day-4-read-replicas-and-replication-lag/6ad97f46fe6584e965eff0fc/comment/6ada0d116bed55b873dade9e)

One caution on the session-based pin: keep it narrow. Pinning every read for a few seconds after any write sends the whole dashboard to the primary, including the heavy catalog queries the replicas exist to serve. I pin only the read-your-writes route itself, My Orders in this case, and leave everything else on the replica. Lag protection only earns its cost where a stale row actually breaks the flow.

[Anish Ansari](https://hashnode.com/@anish78)

[Oct 22](https://hashnode.com/posts/system-design-drill-day-4-read-replicas-and-replication-lag/6ad97f46fe6584e965eff0fc/comment/6ada0d116bed55b873dade9e#reply-6ada0e827b6785cabc4c2ac2)

Fair point Kamran, pinning only the route that actually needs read-your-writes is the better default. Pin everything and you've just moved the catalog load back onto the primary, which is the problem the replicas were there to solve.