Scaling

The reflex, when a site feels slow or a launch looms, is to buy scale: a bigger box, a CDN tier, a queue, a second service, a cache in front of the cache. The corrective is one line — scaling is a diagnosis, not a purchase. You do not buy your way out of a performance problem you have not measured. You find the actual bottleneck and remove it, and most of the time the bottleneck is something the architecture created and something the architecture can delete.

Start with what the workload actually is. A great many sites — every site this engine is built for — are content: rates, photos, copy, a contact form. That workload is read-heavy, cacheable, and small. It does not need horizontal fan-out; it needs to not be slow in the first place. The budgets from the first chapter are that diagnosis applied ahead of time. Zero client JavaScript means there is no bundle to grow, no hydration to profile, no framework runtime to boot before the page is usable. A page under sixty kilobytes fits in a round trip, so it is fast on a phone on a train, not just on a fast connection. No build step means nothing to scale in a pipeline. Ten dependencies mean almost nothing to patch, upgrade, or wait on. A single process rendering HTML from a local database file has almost no moving parts to overwhelm — you cannot have a thundering-herd problem in a tier you never added.

This is not a claim that nothing ever needs to scale. It is a claim about order of operations. Before you add a tier, measure — you cannot secure or fix what you cannot see (Law 16). Ask what is actually slow, and for whom: the server's time to first byte, the size of what you ship, the number of requests the page makes, an unindexed query, an image served at full resolution? Each of those has a specific fix, and the case study in this guide measures exactly these things — client JavaScript shipped, requests per page, installed footprint — so the question gets answered with numbers instead of vibes. Most conversations that begin we need to scale end when someone finally reads the numbers and finds the site was shipping half a megabyte of JavaScript to render text.

The lightweight architecture is not a limitation you will outgrow; it is the thing that keeps the diagnosis honest. When the day comes that a real bottleneck demands a new tier — a genuinely write-heavy feature, a real spike — you add exactly that tier, deliberately, because you measured it (Law 10, the smallest reversible change). You do not wear scale as a uniform before you have the problem it solves.