Most systems do not fail at scale because of traffic. They fail because decisions that were reasonable at a hundred users — a single database doing everything, no tenant isolation, work done inline instead of queued, billing edge cases ignored — become expensive to reverse exactly when the business least wants to stop and reverse them.
A short list of those decisions is worth making properly on day one. Everything else is better deferred.
Worth deciding early
Tenant isolation. How customer data is separated is architectural, and changing it later means touching every query and migrating live data. Decide it deliberately even if you have one customer.
The data model. The most expensive mistake available. Renaming a column is trivial; discovering that a thing you modelled as one record is actually two, after a year of data, is not.
Identity and permissions. Roles bolted on afterwards produce a permission system nobody fully understands, which is how access bugs happen. A simple, correct model from the start survives growth.
Where work happens. Anything that can be slow — sending mail, generating documents, calling third parties — belongs off the request path from the beginning. Retrofitting a queue means finding every inline call.
Safe to defer
Microservices. Almost always. A well-organised single application takes a product a long way, and splitting later along boundaries you have learned is far better than guessing them now.
Caching. Add it when you have measured what is slow. Added early, it hides the real problem and introduces invalidation bugs.
Multi-region. Genuinely expensive, rarely needed as early as it gets proposed.
Fine-grained observability. Structured logs and error tracking from day one; full tracing when you have something to trace.
What actually breaks first
In our experience, in this order:
- The database, on one query. Nearly always a missing index or an N+1 that was invisible at small data volumes. Cheap to fix once you can see it, which is why query-level visibility earns its place early.
- Background work. A queue that was fine until one slow job blocked everything behind it. Separate queues by urgency before you need to.
- Third-party rate limits. Your growth hits someone else's ceiling. Handle backoff properly the first time.
- Billing edge cases. Upgrades, downgrades, proration, failed payments, refunds, tax. Each ignored case becomes a support ticket and a revenue discrepancy, and they arrive together.
- The admin interface. Support asks engineers to run queries. That is a scaling problem in people, and it is the one most often missed.
Note how little of that list is traffic.
The enterprise readiness cliff
At some point a larger customer arrives and asks for SSO, audit logs, role granularity, data export and a security questionnaire. These arrive as blockers during procurement rather than as feature requests, and they arrive with a deal attached and a deadline.
The audit log is the one worth building early, because retrofitting it means finding every state change in the system. The rest can wait, but know they are coming.
Cost per customer
Infrastructure and AI inference costs scale with usage. If nobody is measuring cost per account, gross margin erodes invisibly and you find out from finance rather than engineering.
Instrument it early. It is cheap to add and awkward to reconstruct.
The principle
Make the decisions that are expensive to reverse. Defer the ones that are not. The common failure is inverting that — building microservices and multi-region infrastructure for a product with forty users, while the data model quietly makes a wrong assumption that will cost a year to unwind.
- saas
- architecture
- scaling
- product