What startup engineering taught me about boring technology
Five years of moving fast: the outages, the rewrites we skipped, and why Postgres is still the answer.
This is placeholder content. Edit or delete it from the CMS at
/admin.
There’s a moment at every startup where someone proposes rewriting the queue system. The current one is “not going to scale.” The new one is elegant, distributed, and written in a language nobody on the team ships daily. I have been that someone. This post is my apology.
The taxonomy of boring
Boring technology isn’t old technology. It’s technology whose failure modes are documented. Postgres is boring because when it breaks, forty thousand people have already broken it the same way and written about it. Your bespoke event-sourcing layer is exciting because when it breaks at 2 a.m., you are the documentation.
What actually needed scaling
In five years, here’s what actually fell over:
- An unindexed query that was fine at 10k rows and lethal at 10M.
- A webhook consumer with no idempotency key.
- Me, in Q3, twice.
Notice what’s not on the list: the framework, the language, the monolith. The monolith was fine. The monolith is always fine.
The rule I use now
Spend your innovation tokens on the product, not the plumbing. Users can’t tell your queue is distributed. They can absolutely tell your search is bad.