Boring Architecture, Exciting Products

There is a particular kind of resume-driven architecture that looks impressive in a design doc and costs you a year of your life. We nearly built it at Intactic — event-sourced services, a streaming backbone, polyglot persistence, the full conference-talk starter pack. Instead, we shipped a monolith on Postgres with a cron scheduler, and that decision is quietly the reason we reached $1.2M ARR with a twelve-person team.

The real cost of interesting infrastructure

Novel infrastructure does not just cost setup time — it costs every future hire six weeks of context, every incident an unfamiliar failure mode, and every feature a negotiation with distributed-systems physics. Boring infrastructure, by contrast, has a property that never shows up in benchmarks: when something breaks at 2 a.m., someone on your team already knows how to fix it, because the whole internet already has.

“Pick the dull choice every time the dull choice is sufficient — and spend the saved novelty budget on the product, where novelty is actually felt.”

Our entire automation engine — the thing 300 companies run their operations on — is a Postgres table of jobs, a worker pool, and a scheduler that fires every five seconds. Engineers who join us are productive in days, not months. When we hit a tenfold traffic spike from a viral customer, Postgres did not blink; we resized an instance and went back to building.

Where boring ends

Boring is not an excuse for negligence. The discipline is in knowing which axis deserves the excitement. We are deeply un-boring about three things: the automation DSL our customers write, the correctness of our billing ledger, and the latency of our dashboard. Those are the surfaces users touch, where technical novelty translates directly into product delight. Nobody has ever chosen our platform because of our message queue.

• Default to the monolith until a team boundary makes the network boundary obvious — not the other way around.
• Postgres queues, cron, and materialized views cover far more scale than conference talks suggest.
• Reserve your innovation tokens for the layer that is your product, and spend them shamelessly there.

The uncomfortable truth is that infrastructure choices are mostly about what kind of failure you prefer. Exciting architecture fails in novel, ungoogleable ways. Boring architecture fails in boring, well-documented ones — at a scale you will likely never reach. I know which 2 a.m. page I want, and it is the one with a Stack Overflow answer from 2016.