--- title: "Discussion on \"System Design Drill Day 5: Load Balancing and Horizontal Scaling\" | Hashnode" description: "Discussion on \"System Design Drill Day 5: Load Balancing and Horizontal Scaling\". How to go from one Laravel server to three behind a load balancer: algorithms, health checks, stateless servers and safe deploys." url: "https://hashnode.com/posts/system-design-drill-day-5-load-balancing-and-horizontal-scaling/6adad0dea48cd2e249e95924" --- [Feed](https://hashnode.com/feed) / Discussion # [System Design Drill Day 5: Load Balancing and Horizontal Scaling](https://blog.anishansari.com.np/system-design-drill-day-5-load-balancing-and-horizontal-scaling?utm_source=hashnode&utm_medium=feed) How to go from one Laravel server to three behind a load balancer: algorithms, health checks, stateless servers and safe deploys. Oct 23 · 7 min read · blog.anishansari.com.np Read the article - [#system-design](https://hashnode.com/tag/system-design) - [#scalability](https://hashnode.com/tag/scalability) - [#backend](https://hashnode.com/tag/backend) - [#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 74 Markdown supported · ⌘↵ to post [Rishabh Mishra](https://hashnode.com/@rushdeploy) [Oct 25](https://hashnode.com/posts/system-design-drill-day-5-load-balancing-and-horizontal-scaling/6adad0dea48cd2e249e95924/comment/6add706f09e05f7ae4064216) One check before the third server goes live: add up the database connections each box will open. Three servers with their usual worker pools can hit MySQL's limit together, even when traffic looks fine. [Anish Ansari](https://hashnode.com/@anish78) [14h ago](https://hashnode.com/posts/system-design-drill-day-5-load-balancing-and-horizontal-scaling/6adad0dea48cd2e249e95924/comment/6add706f09e05f7ae4064216#reply-6af68cca590228d22a225f14) Linking the runbook from the ticket is a great habit, Rishabh. Whoever picks it up at 2 AM gets the fix steps right there instead of digging for them. [Rishabh Mishra](https://hashnode.com/@rushdeploy) [12h ago](https://hashnode.com/posts/system-design-drill-day-5-load-balancing-and-horizontal-scaling/6adad0dea48cd2e249e95924/comment/6add706f09e05f7ae4064216#reply-6af6a7827fa44f72958736ac) Exactly, that 2 AM case is the one I keep in mind. A link to the runbook in the ticket means the person on call can act first and ask questions later, instead of hunting through logs while the alert is still firing. [Anish Ansari](https://hashnode.com/@anish78) [5h ago](https://hashnode.com/posts/system-design-drill-day-5-load-balancing-and-horizontal-scaling/6adad0dea48cd2e249e95924/comment/6add706f09e05f7ae4064216#reply-6af70b9cacfe7ad30b5b8887) Same here, Rishabh. When the runbook link is sitting right in the ticket, the first few minutes go into fixing things instead of figuring out where to start. [Mahdi Jabinpour](https://hashnode.com/@mahdi-lumowp) [Oct 24](https://hashnode.com/posts/system-design-drill-day-5-load-balancing-and-horizontal-scaling/6adad0dea48cd2e249e95924/comment/6add1206838a42a2d61b83ef) The rolling-deploy exercise would be even stronger with a checkout running while old and new application versions overlap. Database compatibility is one boundary; session payloads and queued-job formats are two more. Testing that mixed-version window makes “any server can handle any request” a property of the release process as well as the steady state. [Anish Ansari](https://hashnode.com/@anish78) [Oct 25](https://hashnode.com/posts/system-design-drill-day-5-load-balancing-and-horizontal-scaling/6adad0dea48cd2e249e95924/comment/6add1206838a42a2d61b83ef#reply-6add8352278d83e4372a7b6e) Agreed Mahdi, the article only covers backward-compatible migrations, but session payloads and queued jobs cross that old and new window too. Running a real checkout through a half-rolled deploy is a nice way to prove it. [Kamran Khan](https://hashnode.com/@kamrankhandev) [Oct 23](https://hashnode.com/posts/system-design-drill-day-5-load-balancing-and-horizontal-scaling/6adad0dea48cd2e249e95924/comment/6adb5d1c1e14674ebf378b5e) One gotcha I'd add from a rollout like this: when you sync APP\_KEY across the new boxes, every existing encrypted cookie dies at the same moment. We watched a chunk of users get bounced mid session during the cutover. If you're on Laravel 11, APP\_PREVIOUS\_KEYS lets you rotate instead of flipping the switch, so old cookies keep decrypting until they expire naturally. Worth calling out before the big sale, not after. [Anish Ansari](https://hashnode.com/@anish78) [Oct 23](https://hashnode.com/posts/system-design-drill-day-5-load-balancing-and-horizontal-scaling/6adad0dea48cd2e249e95924/comment/6adb5d1c1e14674ebf378b5e#reply-6adb60760e2844ea3a4a592d) Good catch Kamran, a hard APP\_KEY swap logging everyone out in the middle of a sale is a painful way to learn that. Rotating with APP\_PREVIOUS\_KEYS so old cookies keep decrypting is the much safer move. [Arnold Holm](https://hashnode.com/@stratcorealpha) [Oct 23](https://hashnode.com/posts/system-design-drill-day-5-load-balancing-and-horizontal-scaling/6adad0dea48cd2e249e95924/comment/6adb48b55ae06650eaeeb4f7) One crash fixture I would add: a worker sends the report email, then dies before recording completion. A scheduler lock stops concurrent starts, but a retry can still repeat that external side effect. Keep the same report/run ID on retry and test the provider's duplicate handling, where supported. Where it cannot deduplicate, record that remaining risk. Would you include that crash point in the Day 3/Day 5 exercise? [Anish Ansari](https://hashnode.com/@anish78) [Oct 23](https://hashnode.com/posts/system-design-drill-day-5-load-balancing-and-horizontal-scaling/6adad0dea48cd2e249e95924/comment/6adb48b55ae06650eaeeb4f7#reply-6adb607f2c8778db47f3b14b) Yes Arnold, that crash point is worth adding, since the scheduler lock only stops two runs starting together and does nothing about a retry repeating the send. Reusing the same run ID and checking it before sending covers most of it, and where the provider can't dedupe you just note the leftover risk. [Abhinav Sharma](https://hashnode.com/@abhinavs1920) [Oct 23](https://hashnode.com/posts/system-design-drill-day-5-load-balancing-and-horizontal-scaling/6adad0dea48cd2e249e95924/comment/6adaf85b48ac65c800153b4f) The readiness-vs-liveness split is the detail most first-time setups get wrong: folding Redis into readiness means one cache blip pulls every server out of rotation at once. The duplicate report email is the other classic: a scheduled job needs a single owner the moment more than one box exists. [Anish Ansari](https://hashnode.com/@anish78) [Oct 23](https://hashnode.com/posts/system-design-drill-day-5-load-balancing-and-horizontal-scaling/6adad0dea48cd2e249e95924/comment/6adaf85b48ac65c800153b4f#reply-6adb0a338c60127c2817e582) Thanks Abhinav, keeping Redis out of readiness is exactly what stops one cache blip from emptying the whole pool. And the duplicate report email is the bug that only shows up the day you add a second server 🙂