Simplicity Under Load: What Breaks and What Does Not

Simple systems are praised in blog posts and doubted in practice. 'Sure, it's simple, but will it scale?' After eight months of running a deliberately minimal stack under real traffic, I can say which parts held and which parts strained. Simplicity scales further than people expect, and it breaks in specific, predictable places.

What Held

Serverless Lambda handlers. No capacity planning. No scaling rules. The platform scaled the handlers to match the load automatically. Zero operational effort on my side for the compute tier.

DynamoDB on-demand. A single-table design with clean access patterns ran without tuning. No hot partition concerns for my access patterns. Costs stayed within the free tier even with real traffic because the access pattern matched the storage design.

Static Next.js on Vercel. Pages served from the edge do not have a scaling story; they just serve. ISR for dynamic content pages held up under spiky load without any tuning.

What Strained

Email sending through SES. The sandbox limit hit at 200 daily sends. Moving out of the sandbox required a support request and a domain verification dance. Not hard, just not instant. Plan the request before you need the throughput.

CloudWatch log volume. Lambda writes more log data at scale than I assumed. By month five, my log retention bill passed my compute bill. Fix: drop log level to warn for successful paths, keep info for error paths, shorter retention for non-production.

The single-admin pattern. I built around one content author: me. When I onboarded two writers, race conditions on publish metadata showed up within a day. Simple for one user is not simple for many.

The Pattern in What Broke

Every strain came from an assumption about volume or concurrency that was fine at month one and wrong at month six. Not architectural mistakes. Implicit capacity assumptions. Writing them down as per-variable ceilings would have flagged each one months earlier.

SES:        daily_sends < sandbox_limit           (breached month 5)
CloudWatch: monthly_log_gb < free_tier            (breached month 5)
Admin:      concurrent_writers == 1              (breached month 7)

The Real Rule About Simplicity

Simple systems scale until they hit an assumption. Then they need a targeted fix, not a rewrite. That is the advantage: each fix is scoped and cheap. Complex systems hit many assumptions at once and the fixes interact. See AWS's Well-Architected Framework for the review ritual; I apply it at smaller cadence.

Simplicity is not a promise that nothing breaks. It is a promise that when something breaks, the fix is local.