Why "Monolith" Became a Bad Word

The term monolith is widely misunderstood. Suggesting a modular monolith these days often prompts polite nods-as if you've missed the memo on what constitutes "modern" architecture.

The Microservices Trap

Microservices have rapidly become the go-to architecture. Teams eagerly spin up isolated services hoping for scalability, maintainability, and independent deployments. Yet this approach often creates unnecessary complexity, especially around data handling and service orchestration.

Common issues include:

• Distributed transactions
• Complex data synchronization
• Operational overhead with multiple databases and services

These problems demand elaborate solutions that ideally shouldn't be needed initially. Ironically, shipping features often slows down rather than accelerating.

The Case for Modular Monoliths

Here's what I've observed repeatedly:

Modular monoliths consistently win in early and mid-stage products.

Why Modular Monoliths?

Because, when starting out, clarity beats complexity.

Modular monoliths offer:

• Structure without overhead
• Speed without chaos
• Clear ownership and rapid iteration

Recently, I advised a startup to ditch microservices for their new product-not out of prejudice, but because their requirements clearly indicated simplicity and rapid development, not complex orchestration.

They didn't need 10 isolated services managed by five engineers from day one; they needed direct momentum.

Real-World Examples: Shopify & Amazon Prime Video

Shopify continues to run successfully on a modular monolith despite immense scale. Amazon Prime Video, initially a microservices-heavy infrastructure, famously reverted to a monolith architecture. Prime Video found that reverting significantly reduced operational complexity, accelerated development, and improved reliability.

Premature complexity is a productivity killer.

Designing Modular Monoliths Properly

The critical aspect is to architect your modular monolith correctly from the start. By strictly following SOLID principles, you ensure each module is:

• Highly cohesive
• Loosely coupled
• Easily maintainable and replaceable

This makes it straightforward to break out specific services into standalone microservices later when your product demands it.

Example: Extracting a User Service

Consider your monolith initially includes a user service. As your user management needs expand, extracting this into an independent microservice becomes straightforward if you established clear boundaries and minimal dependencies from the outset. This extraction supports independent scaling and enhanced functionality with minimal friction.

Adaptability: The Core Advantage

The strength of a modular monolith lies in its inherent adaptability. It lets teams move quickly, iterate freely, and defer complexity until genuinely necessary. Premature optimization is rarely beneficial-it typically bogs down progress.

Final Thought

Remember:

You can always split later-but you can't reclaim time lost to premature complexity.

If engineering giants like Shopify and Amazon Prime Video see value in reverting to modular monoliths, perhaps it's time to reconsider the microservices-first dogma.

Start smart. Start simple. Build modular monoliths that keep your architecture clear, your code manageable, and your momentum strong.

Note: I don't hate microservices. In fact, almost all our mature projects are effectively microservice-based. The key is adopting the right architecture at the appropriate growth stage.