How the architectural pendulum swung towards pragmatism in 2025
In the mid-2020s, something happened in software development that only a few years earlier would have seemed impossible: microservices, an architectural style long considered the only possible future, came to be rethought more and more often: high-profile returns to the monolith made the industry recount the cost of complexity. Companies that had gone all the way from monoliths to breaking everything into services increasingly talk not about scalability and flexibility but about complexity, cost and losing control.
The architectural pendulum has swung back. Not to the old monoliths, though, but to more mature, pragmatic solutions.
The age of the monolith: simple until it got too complex
In the early 2000s, monolithic architecture was the industry standard. One application, one codebase, a shared database, everything running in a single process. This approach made it possible to get started quickly, and most teams understood it.
The problems began as the system grew. Any change risked affecting unexpected parts of the application. Deploying a new version became a stressful operation, and scaling meant scaling up the entire application, regardless of which part was actually under load.
Even so, for many years this was seen as an unavoidable trade-off. Until a few companies decided there was another way.
The rise of service architecture and the promise of a new future
One of the turning points was Amazon’s internal transformation in the late 1990s and early 2000s. The company abandoned direct connections between components and required all interactions to go exclusively through service interfaces. That made Amazon the best-known example of service-oriented architecture (SOA), an approach Gartner analysts had described back in 1996.
Another landmark case is Netflix. After a serious outage in 2008, the company rebuilt its system from the ground up: it moved to the cloud and split its functionality into many independent services. This made it possible to scale individual parts of the system, speed up development and improve fault tolerance.
These examples quickly became the benchmark. The industry drew its conclusion: microservices are the answer to every growing pain.
Microservices as dogma, and the first cracks
Microservice architecture promised a lot:
- independent teams;
- frequent deployments;
- flexible scaling;
- freedom of technology choice.
Companies started breaking up their systems wholesale, sometimes without a clear idea of why a particular component needed to be a separate service. As a result, instead of one complex application there were dozens, and then hundreds, of autonomous parts.
Over time it became obvious that the problems hadn’t gone away. They had simply changed shape.
Function calls turned into network requests. Along came latency, data serialisation and the need to keep APIs compatible. Monitoring and logging became distributed. Debugging became hard and slow. Running the whole system locally on a work computer turned out to be practically impossible.
What used to be an internal implementation detail became an infrastructure problem.
When there are too many services
The costs of microservice extremism showed most clearly at large companies.
Uber and the “Death Star”
Uber, scaling fast, split its system into thousands of microservices: in 2020 there were about 2,200 critical ones alone. The map of connections between them came to look like what engineers call a “Death Star”: a huge number of nodes and a web of calls.
A single user action, such as ordering a ride, required dozens of services to work in concert: geolocation, pricing, driver matching, notifications. Any failure immediately showed up in the user experience.
In response, Uber moved to Domain-Oriented Microservice Architecture: services were grouped into domains, logical blocks responsible for specific business functions. In essence, it was an attempt to regain control and cut down the number of points of interaction.
Twitter and the attempt to “simplify drastically”
Twitter hit the limit too. Its system consisted of a multitude of back-end services, each handling a separate function. In November 2022, right after buying the company, Elon Musk announced that he would switch off most of the microservices as bloat. That same day some users stopped receiving SMS codes for two-factor authentication. Former employees and many media outlets linked the outage to the shutdown of services, but Twitter never officially confirmed the cause.
If that link is right, the episode showed two things at once: the architecture had become too complex to understand even inside the company, and a sharp rollback without in-depth analysis is dangerous. Still, the very fact that simplification was needed was telling.
The return of the monolith, but a different one
Gradually a compromise approach began to take shape in the industry: the modular monolith.
This is not a return to the unstructured systems of the past. A modular monolith is one or several large applications in which the code is clearly divided into independent modules with well-defined responsibilities. They are deployed together but designed so that they can be split out into separate services if needed.
The idea is simple: if parts of a system change and scale together, there’s no point in artificially separating them with network boundaries.
Economics beats ideology
One of the most telling cases is Amazon Prime Video. The team built a video quality monitoring system on a serverless architecture with a large number of small functions.
As it scaled, it turned out that a large share of the costs went not on computing but on communication between components. After analysis, the system was rewritten as a monolithic application.
The result was unexpected: infrastructure costs fell by more than 90%, and scalability improved. In 2023 this became the loudest public admission that microservices are not a universal solution, but not the first: back in 2018 Segment described how it merged more than 140 microservices back into a single service.
Shopify reached a similar conclusion: instead of carving its Rails monolith into microservices, it split it into components with strict boundaries inside a single application. Dropbox chose a middle path: its Atlas platform cut the monolith into more than 200 clusters, each deployed separately, and the company itself calls the approach a hybrid.
How to choose an architecture in 2025
The modern approach relies less and less on fashion and more and more on context.
The key questions look like this:
- Team size. Small teams rarely gain anything from microservices.
- Nature of the load. Are there parts of the system that genuinely need to scale independently?
- Non-functional requirements. Is latency critical? Do you need strict data consistency?
- Budget and expertise. Is the team ready to maintain complex infrastructure?
For start-ups and small products, a monolith is often still the best choice: faster, cheaper, easier to understand. Microservices are justified where they solve a specific, measurable problem.
Bear in mind, too, that architecture is not a final decision. You can start with a monolith and gradually split out services as you grow. Going the other way is possible, but much harder and more expensive.
Instead of a conclusion: the pendulum has come to rest at the point of balance
The history of architectural approaches has shown that extremes rarely work for long. Monoliths became too heavy, microservices too complex. As a result, the industry arrived at a more mature and pragmatic view.
Today architecture is neither a matter of faith nor of following trends. It is an engineering calculation and an honest answer to the question: what problem are we solving right now.
And it is this approach, not the next fashionable acronym, that shapes how systems are built in 2025.
A quick rule for choosing
A monolith is easier to change, test and deploy when the team is small. Microservices are justified when independent scaling, team autonomy or fault isolation genuinely matter more than the cost of a distributed system. Start with domain boundaries, not with the number of services.
Useful articles and discussion here (chat in Russian)
