Microservices or monolith: still a current debate?

In recent years, the debate between microservices and monolithic architectures has occupied a central place in software engineering discussions. On one side, large technology companies have publicized their shift to distributed systems as a symbol of modernity and scalability. On the other, authoritative voices in the industry have begun to reassess monoliths, highlighting how the additional complexity of microservices is not always justified by the benefits they promise. The answer to the question of which approach to choose depends, as is often the case in engineering, on the specific context in which you find yourself operating.

Monolithic architecture: a classic still valid?

A monolithic architecture is an application built as a single cohesive block, where all functionalities coexist in the same process and share the same codebase. This approach, although traditional, retains concrete advantages that should not be underestimated. Development simplicity is perhaps the most immediate benefit: in a context where all functionality resides in the same process, development and testing cycles are faster, dependencies between components are easily verifiable, and understanding the execution flow does not require navigating dozens of separate repositories. Deployment is equally straightforward, since it involves distributing a single artifact, and latency is naturally low thanks to the absence of network communication between components.

When the system grows over time, however, the structural limitations of this choice begin to emerge. Scaling a monolith means scaling it in its entirety, even when only a subcomponent such as the search engine or notification service requires additional resources. Changes in one part of the code can have unexpected effects in seemingly unrelated parts, and the codebase tends to accumulate interdependencies that make every intervention increasingly risky. This phenomenon, often called technical debt, is not inevitable but requires a rigorous architectural discipline that fast-growing teams struggle to maintain.

Microservices: a mature model?

Microservices divide an application into small independent services that communicate through APIs or asynchronous messages, each responsible for a well-defined functional domain. This model has gained enormous popularity largely thanks to the public experiences of companies like Netflix, Amazon, and Uber, which built their platforms on distributed architectures to support millions of concurrent users. The primary advantage is targeted scalability: each service can be scaled independently according to its actual load, optimizing resource consumption and operational costs. Teams can also work on different services in parallel without interfering with each other, and each component can adopt the language or framework best suited to its specific purpose.

However, microservices introduce an operational complexity that should not be underestimated. Network communication between services adds latency and introduces new categories of errors, such as partial failures and distributed data consistency problems, that simply do not exist in a monolith. Monitoring a distributed system requires sophisticated distributed tracing and log aggregation tools, and each service must be secured individually, multiplying potential attack surfaces. The costs of cloud infrastructure and the tools needed to orchestrate and observe a distributed system can be considerable, especially in the early stages when traffic does not yet justify the complexity.

So? Microservices or monoliths?

The real question is not whether to choose microservices or monoliths, but when each of the two approaches is the right one for the context in which you are operating. Monoliths are the most sensible choice for small and medium-sized projects, for proof-of-concept work that needs to be validated quickly, and for teams with limited resources that cannot afford the operational overhead of a distributed system. A well-structured monolith with clear internal boundaries, what some call a modular monolith, offers many of the organizational benefits of microservices without the complications of distribution.

Microservices become an appropriate choice when the system has genuinely differentiated scalability requirements across components, when teams are large enough and specialized enough to work autonomously on distinct domains, and when the required reliability demands that a problem in one part of the system not propagate its effects to the rest. It is significant that many organizations successfully operating on microservice architectures today started with a monolith, and made the transition only when the need was concrete and the additional complexity was justifiable.

The future is in the modular approach

Tools like Kubernetes and cloud-native platforms have considerably reduced the operational cost of managing microservices, making this architecture accessible to organizations that in the past would not have had the means to adopt it. At the same time, the concept of the modular monolith has gained attention as a strategy for preserving operational simplicity while maintaining a logical separation of components that facilitates a potential future transition without requiring a complete rewrite of the system.

In 2025, the debate between microservices and monoliths has stopped being an ideological question and become a pragmatic assessment. It is not the architecture that defines the success of a software product, but the coherence between the technical choices made and the real needs of the context in which that product must evolve. Choosing the right level of complexity for the right moment, without anticipating scalability that is not yet needed and without ignoring structural problems that will accumulate over time, is perhaps the most difficult and most important judgment a development team can exercise.