What does the term scalable web applications mean in your experience?
Scalability has three axes: (1) traffic — handling more concurrent users without degrading latency; (2) code — keeping a growing codebase maintainable as teams and features multiply; (3) operational — debugging, deploying, and observing the system without heroics. Scalable apps invest in module boundaries, code splitting, caching layers, telemetry, and CI gates well before they're 'needed'.
'Scalability' is overloaded. Three distinct meanings — call out which you mean.
1. Traffic scalability
The app handles more users, requests, data without falling over.
Levers:
- CDN caching — static assets at the edge.
- HTTP caching headers — leverage browser + intermediate caches.
- Code splitting — ship only what's needed.
- Server rendering / SSG — fast first byte for SEO + perceived speed.
- API design — pagination, rate limits, batched requests.
- Image/font optimization — AVIF/WebP, woff2 subsetting.
2. Code scalability
The codebase stays maintainable as people and features grow.
Levers:
- Module boundaries — feature folders with explicit public APIs.
- Lint-enforced boundaries — eslint-plugin-boundaries blocks illegal imports.
- Design system — single source of UI truth.
- Typed contracts — TypeScript across components and API responses (tRPC, Zod).
- CODEOWNERS — every file has a team responsible.
- Conventions over rules — prettier, eslint, commitlint.
A 100-page app written by 30 engineers fails not because React is slow, but because no one knows where to add the next feature without breaking five others.
3. Operational scalability
The team can ship and operate without heroic effort.
Levers:
- CI/CD — fast tests, automated deploys, rollback on red.
- Observability — RUM (web vitals), error tracking (Sentry), structured logs.
- Feature flags — decouple deploy from release; kill-switch broken features.
- Bundle budgets — block merges that blow the budget.
- A/B + canary — measure impact before full rollout.
- Runbooks — on-call docs for the top failure modes.
Tradeoffs
Scaling is buying optionality. Each lever costs upfront engineering for future flexibility. The cost is real — premature scaling adds complexity to a small app.
My heuristic: invest when you can predict the constraint. If 'we'll have 50 engineers' is real, invest in code boundaries now. If 'maybe a million users one day' is hypothetical, ship simple first.
Interview framing
Three axes — traffic, code, operational. Most teams I've worked on hit code scalability first: 5 to 50 engineers, the same architecture stops working. The fix was feature boundaries enforced in lint plus a real design system. Traffic was usually solved by CDN + SSR. Operational scaling was telemetry-first: you can't fix what you can't measure.
Anti-patterns
- 'Scalable' becoming code for 'over-engineered'.
- Microfrontends for a 5-engineer team.
- Caching layers on uncached layers — three caches, none reasonable about.
- Building for a Twitter-scale that never arrives.
Scalability is whatever your specific bottleneck will be in 12 months. Investing ahead of that is wisdom; investing further than that is debt with extra steps.
Follow-up questions
- •What's the difference between scalability and performance?
- •How do you decide when to invest in code-scalability?
- •What metrics tell you a frontend app is hitting a traffic limit?
Common mistakes
- •Conflating 'fast' with 'scalable' — related but different.
- •Optimizing for traffic you don't have, at the cost of clarity.
- •Microfrontends before the team is large enough to need the seams.
Performance considerations
- •Performance budgets are the easiest scalability tool to introduce. Set a JS size cap, an LCP target, and a CI gate. Once the team feels the budget, optimizations happen organically.
Edge cases
- •Sometimes a simpler architecture scales further — fewer moving parts.
- •Many scaling problems are organizational, not technical — Conway's Law.
- •B2B vs B2C scalability looks very different.
Real-world examples
- •Linear's monorepo + boundaries plugin (code scalability). Cloudflare's edge caching (traffic scalability). Stripe's docs platform + telemetry (operational scalability). Most large teams pick a mix.