Modularised Microservices and Modularised Monoliths

Overview

While both "modularised microservice" and "modularised monolith" emphasize modularity, they differ significantly in their underlying architectural style and deployment characteristics. Here's a breakdown of the key distinctions:

Modularised Monolith

• Single Deployment Unit: A modularised monolith is deployed as a single unit, even though it's internally divided into modules. All modules reside within the same codebase and share resources like the database.  

• In-Process Communication: Modules within a modularised monolith typically communicate through direct function calls or shared memory, leading to low latency and efficient data exchange.  

• Simplified Deployment: Deploying a modularised monolith is generally simpler than deploying a microservices architecture, as it involves a single deployment unit.  

• Easier Transaction Management: Managing transactions across modules is easier in a modularised monolith because they often share the same database and transaction context.

Modularised Microservice

• Independent Deployment Units: Each microservice, even if further divided into modules, is deployed independently. Modules within a microservice might share resources, but microservices themselves are separate entities.  

• Inter-Process Communication: Microservices communicate with each other through APIs, which involves network calls and data serialization/deserialization, leading to higher latency compared to in-process communication.

• Complex Deployment: Deploying and managing a microservices architecture is more complex due to the independent nature of each service. It requires robust infrastructure for service discovery, load balancing, and fault tolerance.  

• Distributed Transactions: Managing transactions across microservices is challenging due to their distributed nature. It often involves techniques like eventual consistency or distributed transactions.  

Differences

Here's a table summarising the key differences:

Feature	Modularised Monolith	Modularised Microservice
Deployment	Single unit	Independent units
Communication	In-process	Inter-process (APIs)
Deployment complexity	Simpler	More complex
Transaction management	Easier	Challenging
Scalability	Scaled as a whole	Independently scalable

Choosing the Right Approach

The choice between a modularised monolith and a modularised microservice depends on your project's specific needs and constraints. Consider the following factors:

• Complexity: For simpler applications with manageable complexity, a modularised monolith might be a better starting point.

• Scalability: If different parts of your application need to scale independently, microservices offer more flexibility.  

• Team size: Larger teams might benefit from the independent ownership and deployment of microservices.

• Technology diversity: If you need to use different technologies for different parts of your application, microservices allow for greater flexibility.  

In general, it's often recommended to start with a modularised monolith and gradually transition to microservices as your application grows and evolves. This approach allows you to manage complexity, learn about your domain, and make informed decisions about which modules to extract into separate microservices.