Monoliths, Modules, and Microservices: Finding Your Fit

When Olivia, a senior architect based in Seattle, started her 90-day plan at fintech startup Novapay, she immediately initiated a listening tour to take stock of their infrastructure. Although the developers wanted to build a distributed system, Olivia noticed they lacked basic guardrails. She warned them that choosing microservices too early is often a form of premature optimization that leads to a big ball of mud.

While many engineers belittle monoliths as ancient history, they remain the most sensible starting point for small teams. Sean, the CTO of London-based retail platform Cartly, agrees with this sentiment. Even though his engineering team has grown to fifty people, they still rely on a single, well-structured codebase. They actively avoid the operational complexity of managing multiple databases and independent deployments.

Despite the clear benefits of a monolith, a fast-growing company can eventually outgrow it. When this happens, a modular monolith offers a fantastic middle ground. It keeps the deployment simple while enforcing a strict separation of concerns. In spite of having a single codebase, developers can define clear bounded contexts, ensuring that different modules are not tightly coupled in their day-to-day work.

Nevertheless, some teams prefer to jump straight to microservices. At Manchester-based logistics firm TrackGo, Lauren decided to take risks by decomposing their legacy platform into thirty distinct services. Much as she loved the simplicity of their old monolith, the business required strict fault isolation. If their payment service crashed, the tracking system needed to keep running without interruption.

Whereas TrackGo successfully managed this transition, other companies struggle deeply with the resulting inter-service communication. Without a robust service mesh, handling network latency and debugging API failures can overwhelm developers. Managers often feel the need to constantly check up on their teams, fearing that loose coupling has actually resulted in chaotic, untangled dependencies.

Ultimately, the choice of architecture depends heavily on your team’s size and maturity. A small startup should probably avoid microservices, whereas a massive enterprise might find them essential. Before making any major design decisions, leaders must ensure their teams do not let their guard down when it comes to defining clear service boundaries and maintaining high internal cohesion.

To find out where the industry stands today, our magazine recently conducted an extensive survey of five hundred software engineers across the US and the UK. We asked them to describe their current system architecture, expecting a clear division between modern microservices and traditional modular monoliths. However, the responses we received painted a highly unexpected and amusing picture.

While twenty percent of respondents claimed they run a clean modular monolith, and fifteen percent boasted about their microservices, the vast majority were surprisingly honest. Much as we love neat architectural categories, a staggering sixty-five percent of engineers chose the final option on our survey, which simply read: 'I'm not sure, but it's currently on fire.'

Read again and choose the right answer

What did Olivia warn the team at Novapay about?

• That microservices might be premature optimization
• That they needed a bigger budget
• That they should hire more QA engineers

Why does Sean's team at Cartly still use a single codebase?

• They cannot afford to migrate
• They want to avoid operational complexity
• Their developers do not know how to build microservices

Why did Lauren decide to decompose TrackGo's legacy platform?

• To improve network latency
• To achieve fault isolation
• To reduce the number of developers

What was the most popular answer in the magazine's architectural survey?

• Modular monolith
• Microservices
• 'I'm not sure, but it's currently on fire'

Sources: photo by Leeloo The First on Pexels