Every developer of a successful web service knows this progression: You start with a simple FastAPI or Django app. It works great locally. Then you deploy it, traffic grows, and suddenly you're working primarily on infrastructure complexity. Load balancers, cache layers, database replicas, message queues, and before you know it, your simple microservice based business logic has become a complex distributed system mesh including careful cache invalidation logic.
But what if this complexity isn't inevitable? What if it's actually the result of a historical mistake that became "best practice"?
This talk challenges a fundamental assumption of modern web architecture: that stateless services are superior for scalability. I'll demonstrate that this belief, born from the constraints of early web servers, is now actively harmful to both performance and developer productivity. The truth is: separating logic from state (the core of stateless architecture) creates most of the complexity we fight daily. Every database query, every cache lookup, every message queue: they're all workarounds for the fact that we threw away our object's state after each request.
Python developers who:
Just as we moved from manual memory management to garbage collection, it's time to move on from manual state management. Your Python objects should live as long as they're needed, not just for the duration of a request. This isn't theoretical. Systems using this approach power gaming platforms with millions of concurrent users, financial systems requiring microsecond latency, and IoT platforms managing billions of devices. The technology exists. We just need to unlearn the "stateless is good" mantra.
