In the first part, we talked about microservice and its implications on the business domain. When we talk about Microservice, inevitably we must mention the term monolith. This post is about the monolith and its types. Should we start with a monolith or go for microservice right away? In my experience, working in different startups I would go with monolith if I want to deliver a fast MVP. But let's talk about it deeper to better understand the concept.

The Monolith is a system that is deployed all together. It is the opposite of microservice independent deployment principle. So If you have microservices that you must deploy all together, you have a monolith. Now let's visit different types of monolith.

The Single-Process Monolith

The most common type of monolith is a single-process monolith. It is a code that is deployed as a single process. The main characteristic is that they use a single database to read and write. This architecture makes sense for smaller organizations.

The Modular Monolith

When a single-process has separate modules. we call it a modular monolith. It can use a single database. The main problem is that the database lacks decomposition. But to make modules independent we can decompose the database the same as modules.

Shopify is a great example of an organization that has used this technique as an alternative to microservice decompo‐ sition, and it seems to work really well for that company.

The Distributed Monolith

A distributed monolith is a system composed of multiple services, but unlike true service-oriented architecture (SOA), it necessitates deploying the entire system as a single unit. Despite technically fitting the SOA definition, distributed monoliths often fall short of delivering the advantages promised by SOA. In practical terms, they inherit the drawbacks of both distributed systems and single-process monoliths without fully embracing the benefits of either. Distributed monoliths commonly arise due to insufficient emphasis on principles like information hiding and business functionality cohesion where seemingly local changes have far-reaching effects, breaking other components of the system.

Disadvantage of Monolith

1- Single database: Using a single database, especially in a single process monolith.
2- deployment of a large system altogether: This makes the deployment a tedious and error-prone task.
3- Difficult testing: It can be a hard and time-consuming task to test when one part of the application changes.
4- Delivery contention: Multiple teams work on single code and this creates a delivery contention.
5- Large systems can not be scaled in monolith easily

Advantages of Monolith

Monoliths, including single-process or modular monoliths, offer a range of advantages, simplifying deployment topology and mitigating challenges linked with distributed systems. They provide streamlined developer workflows and simplify activities like monitoring and troubleshooting. Additionally, code reuse within a monolith is straightforward, eliminating the complexities of deciding how to share code in a distributed system. Monolith should not be considered as legacy system and it is a valid choice for many scenarios.

In the next post, we talk about the advantages of microservice.

Read previous post: the fundamentals here