Building for 10× the users you have today

The most expensive engineering mistake you can make isn't choosing the wrong framework. It's designing for the scale you have today instead of the scale you'll need in eighteen months.

Database: read vs. write separation from day one

Most applications are read-heavy. If your database architecture treats reads and writes identically, you're leaving performance on the table and setting yourself up for a painful migration later. Structure your queries so read replicas can be added without code changes.

Stateless application layer

If your application servers hold state — sessions in memory, files on disk — you've built a ceiling on horizontal scaling. Make application servers stateless. Sessions in Redis. Files in S3. Externalise everything a server generates that another server might need.

Queue everything that doesn't need to be synchronous

Email sends, webhook deliveries, PDF generation — none of these need to happen in the request/response cycle. Every synchronous operation that could be asynchronous is a latency liability and a potential timeout waiting to happen.

The N+1 problem will find you

A list page that makes one database query per item looks fine at 20 items. At 2,000 items and ten concurrent users, it's a crisis. Instrument your queries before you go to production.

The 10× question

At the end of every architecture review, we ask: if this system needed to handle 10× the current load tomorrow, what breaks first? The answer tells you where to invest before you need to.