Faith Sodipe

We had a scaling problem. Everyone said Kubernetes. We said no and scaled anyway. This is the story of what we built instead, what we learned, and why the most powerful engineering decision we made was knowing what not to build.

Every engineering team hits a scaling problem eventually. And somewhere along the way, the industry convinced us that the answer was always the same, Kubernetes, service meshes, container orchestration, and an infrastructure stack that requires its own dedicated team just to keep the lights on. We have been sold complexity as a sign of sophistication, and a lot of teams are paying the price for it.

This talk is the honest story of what we did instead.

When our production ETL engine started showing signs of strain under growing data volume, we resisted the pull toward heavyweight infrastructure. We containerised with Docker for clean, consistent deployment and then we stopped. We drew a hard line between containerisation as a sensible engineering tool and orchestration as an unnecessary leap, and we scaled our API layer using what our stack already gave us, without the theatre.

We will walk through the real decisions that made the difference, how we diagnosed the actual bottlenecks instead of the assumed ones, how we kept our API surface clean and predictable under increasing load, how we used the tools already available to us before reaching for anything exotic, and what we learned about the true cost of complexity when you are the one maintaining it at 2am.

This is not a talk against Kubernetes. It is a talk about knowing when you need it and having the confidence to say not yet when you do not. Because the most sophisticated engineering decision you can make is sometimes knowing exactly what not to build.

You will leave with a practical framework for making infrastructure decisions that match your actual scale, the language to push back on complexity for its own sake, and a story that might just save your team months of unnecessary work.