HTEC Days | Modular Monolith, 2 years later: Mistakes, Lessons, and What Could Have Been Better

The presentation will introduce the Modular Monolith architecture on a high level, with diagrams and explanations on how to build one. The discussion will then proceed to what the speaker has learned from applying the Modular Monolith architecture on his project over the past 2 years, the mistakes that were made, and the lessons learned from the problems faced.
Speaker:
Milan Jovanović, Application Architect Associate at HTEC

[@dansadventures5514]

It's incorrect to say that the modules can't be scaled independently when deployed together. Each module could use a separate threadpool for doing its work so you could configure the orders module to use a threadpool of 40 threads and the customers module to use 10 threads even when both modules are deployed together.

[@bayobizzle]

"You can either scale everything or scale nothing". I want to disagree with this statement. Your modules are in a way independently deployable. You should be able to have multiple copies of a particular module running at the same time. Even better if they have their individual databases. With that they can handle more traffic without actually having to scale the entire system. From a low level perspective I'm seeing each module as a dotnet solution for example which had an entry point like a Rest API. That alone makes it independently deployable.

[@MrSanchezHD]

I suppose this depends on what you would consider a monolith. The usual approach to a modular monolith in C# has the modules as one or more separate projects (.csproj) inside a single solution, so there is not a VS solution per module. When you use projects like this you end up with built assemblies that are then loaded in-memory by a single running monolith process (one deployment artifact). In this case yes, when you scale the monolith, you automatically scale these assemblies/modules (aka everything) as well.
When you envision each module as a dotnet solution like you said, you'll end up with multiple processes. Would you still call this a monolith? I reckon with this you have a fully fledged microservices architecture with only a few caveats that distinguish it from a "typical" microservices architecture: you'll very likely share one version control repository and you'd have the CI/CD process always build/test/deploy all of the applications at the same time. It's an interesting idea though.

[@MilanJovanovicTech]

Well if your modules are independently deployable, then it's not a monolith any longer. Right?