Microservices changed how we think about software architecture. They gave us a language for decomposition, team ownership, and independent evolution. But they also exposed something we’re still struggling with:

Services proliferate. Boundaries blur. “Temporary” integrations become permanent. Architecture slowly drifts into something else; shaped less by intention and more by the interactions between teams, systems, and constraints. The problem isn’t microservices. It’s that we’re still treating complex systems as if they’re controllable.

System drift is the gradual, emergent evolution of a system away from its intended design, driven by local decisions, constraints, and feedback loops.

We’ll look at why systems drift, why some changes stick while others don’t, and how to make small, targeted interventions that move your architecture in a better direction - without relying on top-down redesigns. If you’ve built or operated microservices and found that the hard problems start after the architecture diagram is finished, this talk will give you a way to navigate what comes next.