Microservices vs monolith: choosing the right architecture for your project

Introduction

Every software project starts with the same deceptively simple question: how should we structure this? Get the answer right, and your team ships faster, scales smoothly, and stays sane. Get it wrong, and you spend years untangling a mess of your own creation.

The monolith-versus-microservices debate has been raging for over a decade, and in 2026, it is more nuanced than ever. The early hype around microservices promised infinite scalability and team autonomy—and then the backlash arrived, with high-profile companies publicly walking back overzealous decompositions. Amazon Prime Video moved their monitoring service back to a monolithic architecture in 2023, reducing costs by 90%. The SnapCI team at ThoughtWorks famously merged their microservices back into a monolith after fighting unstable service boundaries for months.

Yet dismissing microservices outright is equally dangerous. Companies like Netflix, Spotify, and Uber successfully run thousands of microservices in production, shipping hundreds of times per day. The truth is neither approach is universally "better"—each solves different problems at different stages of a project's lifecycle. This article gives you a clear, practical framework for deciding which architecture fits your project, your team, and your timeline, without the hype.

What Is a Monolith, Really?

Before choosing sides, let us define our terms precisely. A monolithic architecture means your entire application—user interface, business logic, data access—lives in a single deployable unit. When you want to release a change, you build and deploy the whole thing. Monoliths are not automatically "bad" or poorly structured. A well-designed monolith uses internal modules, clean interfaces, and separation of concerns. Think of it as a well-organised apartment building: all under one roof, but each room has a clear purpose.

The problem arises when discipline slips. Without the physical barrier of network boundaries between components, it becomes trivially easy to bypass module interfaces. A developer under deadline pressure can import a class from a completely unrelated module, introduce a shared database table that couples two domains together, or add a circular dependency that turns the codebase into what Martin Fowler calls a "Big Ball of Mud." This erosion is gradual—you do not notice it in month one, but by year three, every change requires touching five different modules, and test suites take 45 minutes to run.

Monoliths also force you to scale horizontally as a single unit. If your payment processing module gets hammered during Black Friday, you cannot scale just that module—you scale the entire application, including the login page and the admin panel that nobody is using. This is inefficient and, at significant scale, expensive.

What Microservices Actually Are

Microservices take the opposite approach: each business capability runs as an independent service, with its own codebase, its own database, and its own deployment pipeline. Services communicate through well-defined APIs—typically HTTP REST or asynchronous messaging—and no service can touch another service's database directly.

The canonical definition comes from James Lewis and Martin Fowler in their 2014 article that catalysed the movement: microservices are "an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms." The key words are small, independent, and lightweight. A microservice should be small enough that one team can own it end-to-end, independent enough to deploy without coordinating with other teams, and communicate through simple protocols rather than complex middleware.

This architecture emerged from real pain at companies like Amazon, where by the early 2000s, the monolithic codebase had grown so large that a single deployment required coordination across dozens of teams. Jeff Bezos famously issued the "API mandate" around 2002: all teams must expose their data and functionality through service interfaces, no exceptions. This forced modularity through organisational structure—the essence of Conway's Law in action.

Netflix followed a similar path, migrating from a monolithic datacentre application to hundreds of microservices running on AWS after a catastrophic 2008 database corruption that took their DVD shipping operation offline for three days. They open-sourced much of their tooling (Eureka, Hystrix, Zuul), which became the blueprint for early microservices adopters.

The Real Trade-Offs

Martin Fowler's microservices trade-off framework identifies three benefits and three costs, and understanding these is essential before making any architectural decision.

Benefits:

First, strong module boundaries. When modules are separated by network calls, the cost of bypassing an interface is immediately visible—it requires a new API endpoint, authentication, and documentation. This friction prevents the gradual erosion that plagues monoliths. As Fowler puts it, "using microservices increases the probability that you will get better modularity."

Second, independent deployment. Each service can be deployed on its own schedule. A critical security patch to your authentication service does not require rebuilding and re-deploying your entire e-commerce platform. This dramatically reduces the blast radius of each change and enables faster release cycles.

Third, technology diversity. Different problems call for different tools. Your recommendation engine might benefit from Python's machine learning ecosystem, while your payment processing needs the type safety of Go or Rust. Microservices let each team choose the best language, framework, and database for their specific problem.

Costs:

First, distribution pain. Network calls are orders of magnitude slower than in-process method calls. Every service-to-service communication must handle timeouts, retries, circuit breakers, and partial failures. What was once a simple function call becomes a complex dance of distributed systems engineering.

Second, eventual consistency. In a monolith, a single database transaction can guarantee consistency across your order and inventory systems. With microservices, each service owns its own database, so you must design for eventual consistency—a domain where things can be temporarily out of sync, and your business logic must handle that gracefully. This is genuinely hard to get right.

Third, operational complexity. Deploying ten services is not ten times harder than deploying one—it can be a hundred times harder. You need container orchestration (Kubernetes), service discovery, centralised logging, distributed tracing, automated CI/CD pipelines, and a team that understands all of it. Without these operational foundations, microservices become a nightmare.

When Microservices Make Sense

Microservices shine under specific conditions. The first is team scale. When you have more than 15–20 developers on a single codebase, coordination overhead spikes. Merge conflicts multiply. Deployment queues form. Microservices let you split the organisation into small, autonomous teams, each owning their services end-to-end—the pattern Amazon calls "two-pizza teams."

The second condition is independent scaling needs. If certain parts of your system experience disproportionate load, isolating them into separate services lets you scale precisely where needed. A video transcoding service that pegs CPU at 100% during peak hours does not need to drag your user profile service along for the ride.

The third condition is well-understood domains. Sam Newman, author of Building Microservices, stresses that getting service boundaries wrong is expensive. The SnapCI team at ThoughtWorks built an initial set of microservices, discovered their boundaries did not match the actual problem domain, and spent months fighting cross-service changes. They eventually merged everything back into a monolith, stabilised the domain model, and then extracted services later—successfully, that time. If you are still learning what your product even is, do not distribute it yet.

A useful heuristic: almost all successful microservice stories start with a monolith that grew too large and was intentionally decomposed. Almost every greenfield microservice project I have seen ended up in serious trouble. Fowler calls this "Monolith First," and while it is not an absolute law, the pattern is striking enough to treat it as the default strategy.

When a Monolith Is the Right Call

For most projects—especially new ones—a monolith is not a compromise; it is the optimal choice. Startups building their first product do not have the team size, operational maturity, or domain clarity to justify microservices. A well-structured monolith lets you iterate fast, refactor freely, and figure out your business before you invest in distribution.

Even at surprising scale, monoliths can work. Shopify runs one of the largest Ruby on Rails monoliths in the world, processing billions of dollars in transactions. They have invested heavily in modularisation within the monolith—clear module boundaries, disciplined database access patterns, and a sophisticated CI pipeline. Their approach proves that you can have strong modularity without network boundaries if your engineering culture enforces it.

For Belgian SMEs building internal tools, customer portals, or B2B platforms, a monolith is almost always the right starting point. Your team is likely small. Your domain will evolve as you learn from users. The operational overhead of Kubernetes, service meshes, and distributed tracing will slow you down more than any architectural elegance will speed you up. Build a clean, modular monolith first. Extract services later, when—and only when—you have a clear reason.

The Modular Monolith: A Pragmatic Middle Ground

If the binary choice between monolith and microservices feels limiting, that is because there is a third option that has gained significant traction in recent years: the modular monolith.

A modular monolith is structured internally like a set of microservices—each business domain owns its code, its database tables, and its public interface—but it runs as a single deployable process. The boundaries are enforced by convention and tooling (architecture tests, module dependency checks in CI) rather than by network topology. This gives you clean separation of concerns without the operational burden of distributed systems.

The critical advantage is that refactoring boundaries is cheap. In a microservices architecture, moving a piece of functionality from one service to another is a multi-step migration with API versioning, data synchronisation, and coordinated deployments. In a modular monolith, it is a simple code refactor. When you are still learning your domain—which, for most projects, lasts far longer than anyone wants to admit—this flexibility is invaluable.

The modular monolith also serves as the ideal stepping stone to microservices. Once boundaries stabilise and a specific module genuinely needs independent scaling or a different technology stack, you extract just that module into a separate service. The rest of the system stays monolithic, and you have added only the complexity you actually need. This is how Shopify operates, and it is how many pragmatic teams are choosing to work in 2026.

The Decision Framework

Here is a practical framework for making this decision, adapted from the combined wisdom of Fowler, Newman, and years of industry experience:

Start with a monolith if:

• Your team has fewer than 15 developers
• You are building a new product and still discovering the domain
• Your scaling needs are predictable and moderate
• You lack operational infrastructure (Kubernetes, CI/CD pipelines, monitoring)
• You need to ship fast and iterate based on user feedback

Consider a modular monolith if:

• Your team is growing but not yet at microservice scale
• You have clear business domains but want deployment simplicity
• You want to prepare for future extraction without paying the full distributed-systems tax now
• Your application is organically complex but not at massive scale

Extract microservices if:

• Specific modules genuinely need independent scaling
• Different parts of the system benefit from different technology stacks
• Multiple teams need to deploy independently on different schedules
• You have clear, stable domain boundaries
• Your operational maturity can handle distributed systems

Start with microservices if:

• Your team has significant microservices experience
• You are replacing a well-understood legacy system with stable boundaries
• Your organisation is already structured around autonomous teams
• The domain is well-established and unlikely to shift significantly

A mental model that helps: the cost of extracting a service from a well-structured monolith is lower than the cost of merging poorly-bounded microservices back together. Erring on the side of starting simpler is almost always the safer bet.

Real-World Belgian Context

For Belgian companies, the architectural choice carries specific considerations. Belgium's tech ecosystem is dominated by SMEs, many of which run small development teams of three to ten people. The operational complexity of microservices—managing Kubernetes clusters, service meshes, distributed tracing, and multi-service CI/CD—requires skills that are expensive and scarce in the Belgian market.

That said, Belgian companies operating in logistics, fintech, and e-commerce often face genuine scaling challenges. A Brussels-based logistics platform handling real-time tracking for thousands of shipments across the Port of Antwerp may genuinely benefit from extracting their tracking and notification services independently. The key is to let the business need pull the architecture, not let architecture enthusiasm push the business.

Belgium also has a strong tradition of pragmatic engineering. The "modular monolith first, extract when needed" approach aligns well with the Belgian business culture of measured, deliberate investment rather than chasing Silicon Valley trends. It is an approach that respects budget constraints while keeping the door open for future growth.

Key Takeaways

Architecture follows organisation, not the other way around. Your system structure should reflect your team structure—this is Conway's Law, and ignoring it is the fastest route to architectural failure.

Monolith First is not a compromise; it is a strategy. Almost every successful microservices implementation began as a well-structured monolith. Starting with microservices on a greenfield project is one of the most reliable ways to over-engineer yourself into a corner.

The modular monolith is your best friend. You can get 80% of the benefits of microservices (clean boundaries, team autonomy, maintainable code) with 20% of the operational cost. This is the pragmatic path for most Belgian SMEs.

Extract services for a reason, not for a trend. Independent scaling, technology diversity, and team autonomy are valid reasons. "Because Netflix does it" is not. Every extracted service adds operational complexity that must be justified by a clear business benefit.

Domain boundaries are everything. Getting service boundaries wrong is more expensive than any architectural choice. Invest time in understanding your domain—use Domain-Driven Design, event storming, whatever method works—before you distribute.

Next Steps

This week: Audit your current architecture. If you have a monolith, honestly assess its modularity. Are there clear, documented module boundaries? Can a new developer understand the codebase structure in a day? If not, start by modularising internally before thinking about extraction.

This month: Run a domain mapping exercise with your team. Identify your bounded contexts using Event Storming or Domain-Driven Design workshops. The output is not code—it is shared understanding of where your natural boundaries lie.

Within three months: If you have identified a module that genuinely needs independent deployment or scaling, plan a single extraction. Extract one service, stabilise it, and learn from the operational experience before extracting a second. Resist the temptation to extract everything at once.

Within six months: Evaluate. Did the extraction actually improve deployment speed or scalability? Did the operational overhead justify the change? Adjust your strategy based on real data, not architectural dogma.

Need expert guidance? Choosing the right architecture is one of the highest-stakes decisions in software engineering. At Omnistack, we help Belgian companies design, build, and evolve software architectures that match their team, their budget, and their ambitions. Contact us to discuss your project.

Conclusion

The monolith-versus-microservices debate has matured from religious war into practical engineering conversation, and that is a good thing. In 2026, the best teams are not the ones that pick a side and defend it—they are the ones that understand the trade-offs and make intentional choices based on their specific context.

Start simple. Build modularity in from day one, even if everything runs in a single process. Let your architecture evolve as your team and your understanding grow. Extract services when you have a clear reason, not before. This approach may not look as impressive in conference talks, but it ships software that works, scales when needed, and keeps your team productive and happy.

After all, the best architecture is not the one with the most services or the cleanest diagram. It is the one that helps you deliver value to your users, today and tomorrow.