The Microservices Pendulum Swings Back
After nearly a decade of relentless evangelism, the microservices revolution has officially entered its awkward teenage phase. ThoughtWorks quietly moved “microservices by default” to the Hold category in their March 2026 ThoughtWorks Technology Radar, marking the end of an era that began with Martin Fowler’s blog post and spawned a thousand conference talks about the death of the monolith.
The shift isn’t happening in isolation. Across Silicon Valley and beyond, engineering teams are discovering what those of us who’ve been debugging distributed systems at 3 AM have known for years: breaking everything into nano-services doesn’t automatically solve your problems. It just gives you more interesting ways to fail.
What’s emerging isn’t a return to the bad old days of monolithic monsters that take four hours to build and deploy. Instead, we’re seeing the rise of what I’m calling “right-sized services” — architectures that optimize for team productivity and system comprehensibility rather than service count. The pendulum is swinging, but it’s landing somewhere smarter than where it started.
The Great Consolidation: When Less Became More
Uber’s engineering team published perhaps the most honest postmortem of the microservices era earlier this year. They documented their journey from 2,200 individual services down to 800 consolidated components. The results speak for themselves: a 34% reduction in operational complexity while maintaining the deployment independence that made microservices attractive in the first place.
The Uber case study reads like a greatest hits album of distributed systems pain points. Service discovery nightmares, cascading failures that required a PhD in graph theory to debug, and the delightful experience of trying to trace a request across seventeen different services just to figure out why a user couldn’t update their payment method. Their solution wasn’t to abandon service boundaries entirely, but to redraw them along lines that actually made sense.
Monzo Bank followed a similar path, merging 67% of their microservices while preserving team autonomy and deployment flexibility. The key insight from their architecture review was that service boundaries should follow business domains, not organizational convenience. When your user registration flow spans twelve different services maintained by eight different teams, you haven’t achieved loose coupling. You’ve just distributed your tight coupling across the network.
The Modular Monolith Renaissance
While everyone was busy splitting their applications into ever-smaller pieces, a quiet revolution was brewing in the modular monolith space. GitHub repositories focused on modular architecture patterns saw 156% growth in stars this year, with Shopify’s modular_monolith gem leading the charge among Ruby developers.
The modular monolith pattern represents something like the best of both worlds: you get clear service boundaries and independent development workflows, but you deploy everything together in a single process. No network calls between your user service and your authentication service. No distributed transaction headaches. No service mesh configuration files that look like they were generated by a particularly sadistic AI.
What makes this approach work is discipline around module boundaries and interfaces. You’re still writing loosely coupled code, but you’re not paying the operational overhead tax that comes with running dozens of separate services. When done right, you can extract individual modules into standalone services later if you actually need the independent deployment and scaling that microservices provide.
The Science of Service Sizing
Netflix’s research team has been quietly studying the optimal size for service boundaries, and their findings are both unsurprising and profound. The Netflix Engineering blog on service sizing documents what many of us suspected: the ideal service size correlates strongly with team cognitive load, with 7±2 developers per service boundary emerging as the sweet spot.
This aligns perfectly with Miller’s Rule from cognitive psychology — the same principle that explains why we can remember seven-digit phone numbers but struggle with longer sequences. When a service becomes too large for a small team to hold in their collective heads, it’s time to split it. When services are so small that understanding a single user workflow requires mental context switching across multiple teams, it’s time to consolidate.
The Netflix research also confirms what many of us learned the hard way: service boundaries are primarily a social construct, not a technical one. The most successful service architectures map cleanly to team structures and business capabilities. Conway’s Law isn’t just an observation about organizational dynamics. It’s a design principle.
Building for Humans, Not Slide Decks
The right-sized services movement represents a maturation of our understanding of distributed systems design. We’ve moved beyond the binary choice between monoliths and microservices toward something more sophisticated: architectures optimized for the humans who have to build, deploy, and maintain them.
This doesn’t mean microservices are dead or that everyone should immediately consolidate their architectures. Netflix still runs thousands of services because they have thousands of engineers and legitimate needs for independent scaling and deployment. But for most organizations, the right answer lies somewhere between “one giant application” and “one service per database table.”
The key insight driving this shift is that architectural decisions should optimize for developer productivity and system reliability, not conference talk fodder. When your monitoring dashboard looks like a subway map and your deployment pipeline requires a dedicated team to maintain, you’ve probably overcomplicated things.
As we move forward, I expect to see more organizations adopting a pragmatic approach to service boundaries: start with clear modules within a single deployment unit, extract services only when you have compelling reasons for independent operation, and always remember that the best architecture is the one your team can actually understand and maintain. The future belongs not to the most distributed systems, but to the most comprehensible ones.
What’s your experience been with service sizing decisions? I’d love to hear how your team has navigated these trade-offs, especially if you have war stories from the microservices trenches.
