I started my career at a small e-commerce company, as the third engineer on a tiny team. We had no customers and not even a product yet. It was the early 2010s, the microservices hype had just started, and we designed everything as microservices: user management, saving designs, rendering, a few others, plus an Angular frontend. We were doing what I now call NDD (Newsletter Driven Development).
At the time it felt wonderful, but boy... the problems started showing up fast. The frontend had to make multiple network calls and coordinate the results. To give you more context, Promise.allSettled() only landed in browsers around 2020, so all this coordination had to be done with an extra layer of messy complexity (in Coffeescript!). On the backend side we had to coordinate deployments: one service had to wait for another to be deployed before it could go live, sometimes causing brief "downtime". Worst of all, every time the business came up with major requirements, we had to scratch our heads about where to make changes and how to coordinate them.
Fast-forward a few years and I joined a fintech company with one big Java monolith and 30+ engineers, where every deployment was a major pain run by a Deployment Manager (!). The slightest bug, even in CSS margins, had to wait for a specific deployment day, and every rollback hurt.
And now you can ask me, "So what do you prefer?", and after almost 15 years in the industry I would just say: "Solve the problem you have NOW, not the one you think you will have in the FUTURE."
In the first case we never should have started with microservices, because we had no traffic, no separate teams, just hype. In the second case the company should have started splitting the giant monolith so it could move faster.
Two years ago a team I know spent twelve months breaking a monolith into microservices. This year they are consolidating them into a "modular monolith", substantially back from where they went. Both migrations were well reasoned, documented, and technically sound. The monolith was hard to deploy independently across teams, and the microservices created operational overhead nobody had budgeted for.
They were right both times.
The cycle
Mainframes gave way to distributed systems. Distributed systems gave way to service-oriented architecture. SOA gave way to microservices. And now, microservices are quietly giving way back to modular monoliths.
Each swing is genuinely motivated. Microservices solved real problems: independent deployability, team autonomy, isolated failure domains. The teams at Netflix, Amazon, and Uber that pioneered this at scale were not following fashion (unlike the majority of the rest of the industry). They were solving real operational constraints that a monolith couldn't address at their size.
The trouble is that the benefits arrive early and the costs arrive late.
When you split a monolith, the benefits are nearly immediate. Teams stop blocking each other. Services deploy on independent schedules. Everyone is happy for roughly a year.
Then the costs materialize.
Early on the distributed complexity feels manageable. You only have a handful of services, and the team that built them understands the domain and the boundaries they drew.
By year two, services call each other in ways nobody planned for. Work that should be a single transaction becomes two async calls and a saga. Oncall shifts from checking one log file to chasing traces across many services, some owned by teams that no longer exist. Data that used to be a join becomes an API call that times out.
By year three, many of the original decision-makers have left. Their successors inherit the architecture, experience the costs, and never felt the pain that motivated it. That is the structural problem: one group gets the benefits, another pays the bill, and the system still produces a bad outcome even if nobody acted irrationally.
What the modular monolith actually gets right
The move back toward modular monoliths isn't nostalgia. It's about keeping the benefits that matter, clear ownership and separated concerns, while shedding unnecessary costs.
The key insight is that independent deployability and loose coupling are not the same thing. You can have highly cohesive, loosely coupled modules inside a single deployment boundary. Most coupling in a monolith is knowledge coupling, modules that know too much about each other's internals. That's a design problem you can solve without a network hop.
The situations that genuinely warrant microservices are narrower than the industry believed in 2015: scaling needs that differ by orders of magnitude between components, or failure isolation so critical that one service crashing must not affect another. Most applications never hit these requirements at a scale where the costs are worth paying.
It will swing again
It will. Modular monoliths will grow until independent deployability becomes a real constraint. An outage where one module takes down everything will trigger a post-mortem recommending service isolation. Someone will write a widely shared post. Microservices will look reasonable again.
Engineers who lived through consolidation will remember the distributed systems pain and resist. Engineers who joined later will see the outage data and push for isolation. Both will be reading real evidence. Neither will be entirely wrong.
I wrote recently about how architecture decisions expire while their justifications decay. The pendulum is the industry-level version of the same problem. The conditions that made microservices the right answer applied for a period. They apply less for many teams now. They will apply again as those teams grow.
The question that actually matters
The question is not "monolith or microservices?" It is: which specific costs are you currently paying, and which costs are you willing to take on next?
Teams that navigate this well made the original decision with an explicit list of what they expected to give up. Teams that navigate it poorly adopted a pattern because the industry endorsed it, without a clear theory of which problems they were solving or deferring.
There is no final answer, only the current evidence for your team size, your operational maturity, and your failure modes.
And then a date in the calendar to ask the same question again.