"It works fine in testing" is the most expensive sentence in software. When an app falls over und..."It works fine in testing" is the most expensive sentence in software. When an app falls over und...
The network for creativity
Join 1.25M professional creatives like you
Connect with clients, get discovered, and run your business 100% commission-free
Creatives on Contra have earned over $150M and we are just getting started
"It works fine in testing" is the most expensive sentence in software.
When an app falls over under real traffic, the instinct is to go looking for slow code. Profile the endpoints, optimise a query, add an index. Sometimes that helps. Usually it doesn't, because the problem was never speed.
It's sharing.
Every request in your system competes for the same handful of things, and they don't all scale the same way:
App servers are easy. They're stateless. Add another one, put a load balancer in front, done. This is the part everyone gets right.
Session state is where it first goes wrong. If sessions live in one process's memory, adding a second server means half your users randomly get logged out. Now you're debugging something that only happens in production, at peak.
The database is the real limit. Every request eventually queues behind one writer. You can't clone your way past this one — you have to reduce what reaches it. Read replicas, caching, queues in front of writes.
The pattern is that the bottleneck keeps sliding down the stack until it hits the thing you can't duplicate. Then you have to actually design.
Where did yours break first? For me it's almost always been session state — it's the one that survives testing and dies on launch day.
Post image
Back to feed
The network for creativity
Join 1.25M professional creatives like you
Connect with clients, get discovered, and run your business 100% commission-free
Creatives on Contra have earned over $150M and we are just getting started