Monolith or Microservices? What's the middle ground?

The choice of whether to use Monolith Architecture or Microservices is often a major debate in the Software Engineering circles. This article gives a simple guideline on when to use which.

Monolith

Monolith is often preferrable approach when you have small tech team building a product. Some products at their infancy are just good being a monolith as its a cheaper approach in terms of complexity and human resource. Though it has its own downsides and this is the fact that a monolith can grow into a monster as the code grows. Most times such systems become difficult to modify. There are several intelligent approaches to this as I'll share shortly.

Microservices

Microservices is often the go to architecture when your system scales. At this point resilience and modularity becomes a major concern. As a rule of thumb you know you need microservices the moment an undesirable downtime affects the entire system while you could have simply isolated the culprit if it were a microservice Architecture.

What's the middle ground? Modular Monolith.

Modular monolith gives a fine middle ground for easy migration from monolith to microservices. It's an architectural pattern inspired largely by Domain Driven Design. The major task here is to identify your system's bounded contexts and ensure there are minimal external dependencies within these contexts. Each bounded contexts exposes interfaces for interactions with external contexts. With a modular monolith you would have to trade off relationships across contexts at your data layer for redundancy to ensure there is no tight coupling within your data layer.

In summary, a modular monolith approach is an elegant way of designing your system such that you are ready to scale when need be.

Cheers.