Eight engineers, forty million requests: a case for boring architecture

Stackwell deploys and runs apps for forty thousand teams. It handles forty million requests a day, and its core is maintained by eight engineers. It is one application, one primary database, a job queue and a cache. There is no service mesh. There has never been a rewrite.

Daniel explains why this is the most important technical decision Stackwell has made, and why it has to be defended every year. He covers the three moments the company nearly broke the stack apart, the arguments on each side, and what the team did instead. He also shares the operating numbers: cost per request, incidents per quarter, and how long it takes a new engineer to ship to production.

This is not a talk against microservices. It is a talk about choosing complexity on purpose, measuring what it costs, and telling a scaling problem from a boredom problem.

What you will take away

• A practical test for whether a scaling problem needs new architecture or better use of the old one
• The operating metrics Stackwell watches to keep a small team in control of a large system
• How to argue for a simple stack when everyone around you wants an interesting one