Software Architect · Module 14
Scalability is the system's ability to grow along the axis that matters — without a disproportionate increase in complexity and cost.
Vertical scaling · horizontal scaling · partitioning · capacity
You scale a specific load: users, writes, reads, data volume, teams, or regions.
Growth comes in different shapes
A restaurant can grow by adding tables, by adding delivery, by opening kitchens across town, or by speeding up service. Each one is a different architecture.
Vertical scaling adds resources to one node. Horizontal scaling adds nodes. Read replicas help reads, not writes. Sharding helps volume and writes — but complicates queries, transactions, and operations.
The architect has to name the axis of scale. A system that scales well on reads can be terrible at scaling writes. A service that holds up under load can fail to scale organisationally if every change funnels through one team.
Capacity planning beats heroics
It's easier to know the venue's capacity in advance than to open the doors and hope the walls stretch.
Capacity planning answers: how much load do we carry now, what growth do we expect, where's the ceiling, what's the lead time on expansion, and which alarms will fire as we approach the limit.
Without that, the team learns about the limits from users. That's always more expensive.
Scalability should grow out of the real load profile — not out of abstract fear of the future.
Example: a read-heavy product
In a library, thousands of people read the books, but a small team edits the catalogue.
A documentation service has many reads and few writes. The architecture leans on a CDN, static generation, edge caching, and a read-optimised search index. The source of truth stays simple.
That's a good trade-off: reads scale cheaply, writes stay manageable.
Anti-example: sharding before the first customer
Building an eight-lane interchange to a garage with one car is expensive and inconvenient.
The team designs a sharded database, a routing layer, and distributed transactions from day one — while the product is still hunting for market fit. Development slows down, migrations get harder, and the real load is still unknown.
Scalability has to keep a growth path open. It doesn't have to implement every future level today.
- Which axis does the system have to grow along first? - Where's the current capacity limit? - Which signal tells us the architecture has to change? - Can complexity be deferred while keeping a migration path open?