---
title: "Discussion on \"System Design Drill Day 4: Read Replicas and Replication Lag\" | Hashnode"
description: "Discussion on \"System Design Drill Day 4: Read Replicas and Replication Lag\". How MySQL read replicas scale reads, why replication lag breaks read-your-writes, and how to handle it in Laravel."
url: "https://hashnode.com/posts/system-design-drill-day-4-read-replicas-and-replication-lag/6ad97f46fe6584e965eff0fc"
---

[Feed](https://hashnode.com/feed) /

Discussion

# [System Design Drill Day 4: Read Replicas and Replication Lag](https://blog.anishansari.com.np/system-design-drill-day-4-read-replicas-and-replication-lag?utm_source=hashnode&utm_medium=feed)

How MySQL read replicas scale reads, why replication lag breaks read-your-writes, and how to handle it in Laravel.

Oct 22 · 7 min read · blog.anishansari.com.np  
Read the article

-   [#system-design](https://hashnode.com/tag/system-design)
-   [#mysql](https://hashnode.com/tag/mysql)
-   [#databases](https://hashnode.com/tag/databases)
-   [#laravel](https://hashnode.com/tag/laravel)
-   [#interview-preparation](https://hashnode.com/tag/interview-preparation)

## Written by

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

@anish78 · kathmandu, Nepal

  
[View profile](https://hashnode.com/@anish78)

Food,Code and Cloud Computing. You can support here :https://www.buymeacoffee.com/anishansari

## Responses 4

Markdown supported · ⌘↵ to post

[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.

[Abhinav Sharma](https://hashnode.com/@abhinavs1920)

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

The empty My Orders page right after checkout is the textbook read-your-writes failure. Sending the reads that follow a write to the primary for a short window is usually cheaper than making the whole app strongly consistent.

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

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

Thanks Abhinav, that empty My Orders page is exactly the bug that makes people think their order failed. Pinning reads to the primary for a few seconds after a write fixes it without paying for strong consistency everywhere.
