Modular Monolith and Microservices: parallel work, independent deployments and organization scalability
2025-11-28
One of the most useful traits of Modularity done properly is Autonomy: modules - folders or versioned packages in a modular monolith, separately deployed microservices - are as independent from and as unaware of each other as possible. It has at least three important implications.
Modular Monolith and Microservices: Data ownership, boundaries, consistency and synchronization
2025-11-14
Virtually every module - folder or versioned package in a modular monolith, separately deployed microservice - must own or at least read some data to provide its functionality. As we shall see, the degree to which module A needs data from module B is often the degree to which it depends on this module; functionality being another important dimension of dependence. This leads us to the following principles...
Modular Monolith: dependencies and communication between Modules
2024-05-19
Before talking about module communication, it is important to emphasize the consequences of chosen module design. Problems that we will face when communicating between modules, how often and how much of communication there will be, depend mostly on decided modules structure ... Assuming that we have modules that depend very little on each other, but sometimes they do need to talk with each other - how can they and when they should?
Modular Monolith and Microservices: Modularity is what truly matters
2023-11-26
Modularity is a crucial concept when designing and creating software. Independent of whether our chosen architecture style is to have a single unit of deployment - Monolith or multiple units of deployment - Microservices/Services. It is a quality that should be treated completely independent of how many deployable units of software we choose to have.