The microservices revival is over. Monoliths are back.
Except — that's the wrong lesson.
Most "microservices" weren't microservices. They were distributed monoliths. Services sharing the same database. Shared libraries coupled to deployment cycles. A call graph that touched eight services to render one page. We didn't decompose the system — we decomposed the org chart.
Conway's Law did what it always does. The architecture mirrored the team structure. And when the team structure had fuzzy boundaries, so did the services.
The comeback isn't about monoliths vs. microservices. It's about doing the bounded-context work first. Start with a modular monolith — compiler-enforced module boundaries, zero cross-module direct calls, clear ownership at the code level. Then carve out a real service when you can name the specific reason: independent scaling, independent deploy cadence, different SLA. Not "this team wants autonomy."
If you can't name the reason, it's not a service boundary. It's an organisational boundary wearing a network call.
Have you shipped a service you'd now fold back in? What was the boundary that didn't hold?
Top comments (0)