Scaling your system.

You're at zero users and you want to ship today. Everything runs on a single VM. Web server, app code, database, cron jobs, and static files all live on the same machine. One server, one deploy, one place to look when something breaks. Cheap, easy to reason about, and totally fine for a long time. You'll outgrow it the first time the database eats all the memory and takes the app down with it, or the first time you need to deploy without a five-minute outage.

The database is the first thing to escape. Move Postgres onto its own host so it has dedicated memory and disk. Now app crashes don't take the database down with them, and you can scale the two independently. You also get backups, point-in-time restore, and minor version upgrades as a managed feature instead of as a weekend project. The one rule: don't put the DB host on the public internet.

You have two boxes now and almost no idea what either of them is doing. Add three things at once: structured logs, runtime metrics, and product analytics. Logs tell you what your code did. Metrics tell you how the machine feels. Product analytics tells you what users are actually doing inside the app. Wire alerts to the metrics that hurt the business when they break, and ignore the rest. Pages you snooze are worse than no pages at all.

One app box can only handle so much traffic, and a single box means downtime every time you deploy. Put a load balancer in front, run two or three app instances behind it, and make the app stateless so any request can land on any box. Now you can roll deploys one instance at a time with no downtime, and a crashed instance just gets traffic pulled until it recovers. The database is still the ceiling, but you bought a lot of headroom on the app tier.

Static assets and frequently-read data shouldn't touch your origin. A CDN puts your JS, CSS, and images on edge nodes near every user. A cache layer in front of the database lets you skip the round trip for hot reads, sessions, rate limits, and computed results that don't change often. Both buy you raw speed and let the origin breathe. Cache invalidation is the hard part, so start with TTLs before you start with pub/sub-driven busts.

Sending email, generating PDFs, calling third-party APIs, processing uploads, building search indexes. None of that belongs in the request the user is waiting on. Push those jobs onto a queue and let a separate worker pool grind through them. The web tier stays fast even when an upstream provider has a bad day, and you get retries, dead-letter queues, and rate limiting for free. This is also the point where a slow webhook stops being able to take your whole site down.

Your database is the ceiling now. Add read replicas to absorb read-heavy traffic like dashboards, search, and reports. When writes get hot, shard by tenant or user id so each shard owns a slice of the data and no single primary takes the whole load. This is the point where you stop treating the database as a single thing and start treating it as a fleet. Cross-shard joins become harder and transactions get scoped to one shard, so most teams design the partition key before they actually need it.