Why Redis and Docker Are in Almost Every Project I Ship Now

There's a specific kind of bug that used to eat an afternoon: something works on my machine, fails in staging, and nobody can explain why. Usually it came down to environment drift — a slightly different Node version, a missing system dependency, a config file that existed locally and nowhere else.

Docker Removed a Whole Category of Bugs

Once I started containerizing environments by default, that category of bug mostly disappeared. Development, staging, and production run the same image, so "it works on my machine" stopped being a meaningful sentence - if it works in the container, it works everywhere the container runs.

It also changed how I onboard a project. Instead of a setup document with fifteen manual steps, it's often closer to one command and a wait.

Redis for the Things That Shouldn't Hit the Database Every Time

Separately, I've reached for Redis on nearly every recent project that handles any kind of real-time or frequently-read data. Not for everything — Redis is not a database replacement - but for the specific case of data that's read far more often than it changes: session state, computed values, anything you'd otherwise be hitting the primary database with on every request.

The pattern I keep coming back to: cache aggressively at the edges, invalidate precisely, and never let the cache become the source of truth for anything that actually matters if it's wrong.

Where I've Seen It Go Wrong

The failure mode with caching isn't usually "forgot to use it" - it's "cached something and then changed the underlying data without invalidating the cache." A stale cache is often worse than no cache at all, because it fails silently instead of loudly.

My rule now: if I can't clearly state when a cached value gets invalidated, I don't cache it yet. Getting that discipline right early has saved me more debugging time than the caching itself has saved server load.