The Case for Modular Monolith Architecture: ReeTalk Insights

Martin Säfsten -

Feb 12, 2025 12:14:32 PM

The debate between monoliths and microservices is a common topic in software development. At a recent ReeTalk webinar, Martin Säfsten, a developer and architect with nine years of experience, presented an approach that combines the strengths of both: Modular Monolith Architecture. This method aims to keep the simplicity of monoliths while introducing the scalability and maintainability of modular design.

 

 

Webinar Highlights

The session focused on a key question:

How can we design software systems with high module cohesion and low domain coupling, without the complexity of microservices?

Martin explained how modular monoliths offer a practical solution. They combine the straightforward deployability of monoliths with well-defined, independent modules based on domain-driven design. This setup ensures tightly integrated modules internally while keeping the connections between them minimal.

Main points from the talk included:


- Trade-Offs in Architecture: Every design decision has pros and cons, and choosing the right architecture depends on technical, functional, and business needs.
  1. - Setting Clear Boundaries: Modular monoliths work best when domain boundaries are clear, which can be achieved through practices like event storming.
  2. - Team Structure Matters: Martin highlighted Conway’s Law, which shows how team organization impacts software design and can either help or hinder project success.
  3. - Real-World Examples: Large companies opting for modular monoliths over microservices gave practical proof of the approach's value.

Modular Monoliths vs. Microservices

Martin explored the challenges of distributed systems, quoting Simon Brown: “Choose microservices for the benefits, not because your monolithic codebase is a mess.” He showed that modular monoliths can be a simpler and more manageable choice for many systems, especially when starting a new project.


Advantages of modular monoliths include:


  • - Simplicity: Easier deployments and less overhead compared to distributed systems.
  • - Better Performance: Communication happens within the process, avoiding the delays and complexity of network-based interactions.
  • - Improved Testing and Debugging: Having a single codebase simplifies these processes.

However, modular monoliths have limits. For instance, they might not scale as well as microservices, and there’s a risk of creating dependencies between modules over time.


Martin reflected that while the focus was on Modular Monolith Architecture, a secondary goal was to encourage deeper thinking about what makes software architecture effective and when different approaches work best. He noted that he may have spent too much time on these broader ideas but was glad to have reiterated key concepts like Conway’s Law. Participant feedback was positive, and he felt the addition of real-world examples at the end was especially helpful. These examples demonstrated how even large organizations sometimes move back to monoliths for their reliability and simplicity.


Conclusion

Modular monoliths offer a balanced approach for building software. They are simpler to manage than microservices and can still provide scalability and modularity when done right.


As Martin put it: “Monoliths aren’t legacy—they’re a choice.”

 

Watch the reetalk here: