How we architect for scale
Lessons from platforms serving thousands of users.
Scale isn't a moment that arrives suddenly; it's a chain of decisions made early. Most problems we've seen in struggling systems weren't about load — they were about assumptions baked in when the system was small.
Start with the data
The data model is the hardest decision to walk back. Before the first API, we ask: how will these tables grow? Where are the bottlenecks when the numbers multiply tenfold?
State is the enemy of scale
Every piece of state we hold in memory is a constraint on our ability to distribute. We design services to be as stateless as possible, so scaling horizontally becomes a matter of copying, not rebuilding.
Measure before you optimise
Premature optimisation wastes time on problems that don't exist. We add measurement from day one, then optimise what the numbers prove is worth it — not what we assume is slow.
Good architecture doesn't make scaling easy; it makes it boring. And boring is the best outcome we aim for.