Cloud Architecture Decisions We'd Make Again (and One We Wouldn't)

Most cloud architecture advice reads like a vendor comparison chart. What's more useful, once you've actually run a few production systems, is knowing which decisions held up under real usage and which ones you'd quietly reverse if you started over. Here are a few of ours.

Docker everywhere, no exceptions

Containerizing every service — including the small, "it'll never need to scale" internal ones — has consistently paid for itself. The benefit isn't really about scaling; it's about eliminating an entire category of "works on my machine" problems and making deployment a repeatable, boring process instead of a manual one. The one-time cost of writing a proper Dockerfile is small compared to the ongoing cost of environment drift between a developer's machine and production. We'd make this call again on every project, no exceptions.

A managed Postgres instance over self-hosting

For most product-stage systems, the operational overhead of self-hosting a database — patching, backups, failover, monitoring — isn't work that adds value to the product. A managed Postgres instance costs more per month than a bare VM running the same database, and it's worth every bit of that difference the first time a failover happens automatically at 3am instead of paging someone. We'd make this call again for essentially any product that isn't specifically a database infrastructure company.

Redis as a cache, introduced too early on one project

Here's the one we'd undo: on one system, we introduced Redis as a caching layer before we had evidence the database itself was the bottleneck. It wasn't wrong to reach for caching eventually — it was wrong to reach for it as a default rather than in response to a measured problem. The result was an extra piece of infrastructure to run, monitor, and reason about cache-invalidation bugs for, while the actual performance issue turned out to be an unindexed query that a five-minute fix would have solved. We'd still use Redis again — just after profiling shows it's needed, not as a starting assumption.

Cloudflare in front of everything, by default

Putting Cloudflare in front of a service from day one — even a small one — has been a consistently good default: DDoS mitigation, TLS handling, and edge caching for static assets come essentially for free, and it's much easier to have that layer in place from the start than to retrofit it under pressure later. We'd make this call again immediately on any new project.

The actual lesson

The pattern across all of these isn't "always use X" or "never use Y" — it's that infrastructure decisions made in response to a measured, specific need have held up, and the one decision we'd reverse is the one we made speculatively, ahead of any evidence it was necessary. That's a boring conclusion, but it's the one that's actually been true across enough different projects that we trust it now.