So often I see people giving talks about how the microservice architecture is a failure. You end up losing transactional protections, you’ll have to “join” data across a network boundary, and that network boundary is “always” flaky. Wouldn’t it be much better if everything was in one process, where you could enjoy the benefits of transactions, neighboring data is just a method call away and the only network you have to worry about is the database connection?

This of course ignores the benefits of microservices, like the ability to choose the most suitable stack, independent scaling, independent deployments, smaller blast radius of catastrophic failure, or being forced to stay mindful of your domain boundaries.

This last one is the biggest reason I’m skeptical about the modular monolith being a silver bullet that takes the best of both worlds. Will your org really have the discipline to adhere to a modular architecture? I can absolutely foresee “just one” exception to the rule in a shared foundation module that special cases for one feature’s use case. Or “just one” extra method in that neighboring module so that it’ll be easier to call from our feature.

If you say you have the discipline to do that, and/or the tooling to enforce it, by all means go for it. But at that point it becomes an informed decision about the infrastructural and operational requirements of monolith vs microservices. I feel like in most orgs evangelizing modular monoliths, it’s just a return of the big ball of mud monolith.

Especially if you already have a big ball of mud, then it might be actually easier to first separate something from the monolith, clean it up and then if the domain separation didn’t work out, merge it back into the monolith as a now well-defined module with clear borderlines. Can you really invest in a large-scale refactoring of your monolith to enable and enforce a well-designed modular architecture? All while feature teams are still adding some more mud to the ball while you’re trying to do that?

If you can, I salute you. For me it feels easier to introduce a hard domain border through a microservice and work from that. If the org was willing to invest in a massive refactoring and framework design for the modular monolith, might as well invest in an event-driven pipeline for microservices so services could have materialized views of other domains without having to constantly make API calls…