Does it scale (down)?
It’s 2024, and software is in a ridiculous state.
Microservices, Kubernetes, Kafka, ElasticSearch, load balancers, sharded databases, Redis caching… for everything.
Everything’s being built like it’s about to hit a billion users overnight. Guess what?
You don’t need all that stuff.
-
Vertical scaling goes a loooooong way. CPUs are fast. RAM is cheap. SSDs are blazing. Your database? Probably fits in RAM. We used to run entire companies on a single server in 2010. Why does your side project need ten nodes?
-
Your app won’t be a success. Let’s be real: most apps aren’t. That’s fine. Building for imaginary scale? Premature optimization. Grow beyond one instance? You’ll know what to fix then.
Scaling isn’t wrong. But scale down first. Start small. Grow when needed. Optimize for iteration speed.
Benefits of scaling down
-
Deployment: Single server. A VPS. Your laptop. Up in minutes. No clusters. No orchestration. Dev/prod parity for free.
-
Cognitive load: Easier to reason about. Less moving parts. Fewer boundaries.
-
Money: Small. Is. Cheap.
-
Debuggability: Single service means single stack trace. No distributed tracing. No network partitions.
-
Actually Agile: Change code. Deploy. Done.
Next time someone asks you “Does it scale?”, ask them: in which direction?
Previous work
This article was inspired by my work on Bugsink: a self-hosted error tracking tool. If you’re serious about self-hosting, you should be serious about building something that runs on small hardware as well as big: Bugsink can process millions of errors per day on a single dirt-cheap server.
Still, I’m not the first to say this. Here are some other great resources: