Monolithic architecture simplified

This write-up takes a deep dive into monolithic architecture. We will understand what it is and why implement it.

What is monolithic architecture? 

An application has a monolithic architecture if it contains the entire application code in a single codebase. A monolithic application is a self-contained, tightly coupled software application. This is unlike the microservices architecture, where every distinct feature of an application has one or more dedicated microservices powering it.

Recommended Read: Web application architecture explained with a real-world example

Taking the example of a social networking site like Facebook. The application contains various features such as:

• User posts
• Comment system
• Groups
• Marketplace
• Portal Ads
• Photo storage
• Live streaming
• A recommendation system for recommending the latest and contextual content on the platform to the users and so on.

In a monolithic architecture, all the modules will be coded in a single codebase tightly coupled with each other as opposed to having one or more dedicated microservices running respective features.

The diagram below represents a monolithic architecture.

Monolithic apps are simple to build, test, and deploy in comparison to a microservices architecture, where we have the additional overhead of implementing logic to manage microservices (i.e. infrastructure management), facilitate inter-microservice communication and so on.

Monolith to microservices/distributed architecture

Often during the initial stages of a business, teams choose to move forward with a monolithic architecture, intending to branch out into a distributed microservices architecture later.

There have been instances in the past where the dev teams decided to start with a monolithic architecture and later scaled out to a distributed microservices architecture as the complexity grew. Here are a couple of examples:

LinkedIn started as a monolith application called ‘Leo’ connected to a bunch of databases and later transformed into a distributed architecture.

Uber started its service with a monolithic repo. The solo repo held the business logic for matching drivers and riders, running background checks, taking care of the billing and the payment and all the other related functionalities.

As the business gained traction, the engineering team faced issues typical with monolithic repos. The issues of scalability, tightly coupled components, the entire codebase had to be redeployed for one tiny change in the code and so on.

Also, there was always this risk of cascading impact of the code change on the existing functionalities. Single repo implementations needed serious regression testing after deployments. Adding new features was cumbersome. All of these issues needed more developer resources.

The team decided to break free by transitioning to a distributed microservice architecture. I’ve discussed it here. Check it out.

Though these services started with a monolith and later transitioned, I would like to state they started at a time when cloud computing and microservices architecture weren’t the norm. Also, the traffic was limited.

In the present times, starting with a monolith and later migrating to a distributed architecture decision is a tradeoff. We need to bear in mind refactoring and re-writing code has significant costs associated. Dismantling features from a tightly coupled architecture and re-implementing them into separate microservices demands a lot of time and resources.

In the present computing landscape, applications are built and deployed on the cloud. Also, businesses have to move fast. A wise decision is to pick the loosely coupled stateless microservices architecture from the start if we have multiple distinct features in our application and expect things to grow at a rapid pace in the future.

On the flip side, if our requirements are simple, monolithic architecture would suit best. Implementing a microservices architecture in this use case would be overkill. After all, managing numerous modules running in conjunction in a distributed environment isn’t a walk in the park.

If you wish to understand how microservices work together in a distributed architecture and how large-scale distributed systems are designed. I’ve discussed it in my systems design course ‘Design Modern Web-Scale Distributed Applications Like a Pro‘, which is the third course in the Zero to Software Architect learning track. Check it out.

Pros and cons of monolithic architecture

Let’s go through the pros and cons of the monolithic architecture that will help you figure out if you need it to implement your app. 

Pros of monolithic architecture

Simplicity

Monolithic applications are simple to develop, test, deploy, monitor and manage since everything resides in one repository. Things are relatively simple when dealing with one repository averting the complexity associated when handling and monitoring multiple components deployed separately.

Cons of monolithic architecture

Continuous deployment

Continuous deployment is a pain in monolithic applications as even a minor code change in a certain application layer (controller, service, DAO) or a feature necessitates a re-deployment of the entire application.

Regression testing

The downside of the re-deployment of the entire application is that we need to perform a thorough regression testing of the whole application after the deployment. A minor code change in one feature can potentially impact the functionality of other features significantly since all the features are tightly coupled with each other.

Single points of failure

Monolithic applications have a single point of failure. A bug in any application feature can bring down the entire application.

Scalability issues

Maintenance and scalability are a challenge in monolith apps since the components are tightly coupled with each other. As the code size increases, things get trickier to manage. We can’t scale a certain feature separately. Any change made is applicable to all the features of the app. 

Cannot leverage heterogeneous technologies

Building complex applications with a monolithic architecture is tricky since multiple technologies and programming languages need to be leveraged to implement specific features of an application.

Using multiple programming languages in a single codebase becomes a mess, also, oftentimes not possible. Heterogeneous technologies have compatibility issues and microservices architecture suits best to leverage them.

It is tricky to use Java and NodeJS together in a single codebase, and when I say tricky, I am being optimistic. I am not sure if it is even possible.

Not cloud-ready, hold state

Generally, monolithic applications are not cloud-ready as they may hold state in the static variables. Though not all monolith apps are designed that way, it’s a general observation that legacy apps use static variables to quite an extent. An application to be cloud-native, to have consistent behavior on the cloud, has to be stateless.

If you wish to understand the fundamentals of cloud computing in a platform agnostic way including concepts such as continuous deployments check out my Cloud computing 101 course.

When should you pick a monolithic architecture? 

Monolithic applications fit best for use cases where the app requirements are pretty simple; when the application is not that complex. Examples are a to-do list app, a mostly read-only sports news app, an organization’s internal tax calculation app, a similar open public tool, etc.

These are the use cases where the business is certain that the application will have limited features and complexity and will not require any serious expansion in the near future.

Final words 

We’ve been through the pros and cons of monolithic architecture and the use cases of when to pick a monolithic architecture to build your app, but I would like to state a fact that is above all. When building/designing software, there is no formula or a strict rule of thumb that for a use case X, we need to pick an architecture Y.

There are always tradeoffs involved and you should pick what works best for your use case. To reinforce my statement, I would give the example of Stackoverflow.com. It started as a monolith and is still a monolith, handling 4 billion requests per month, 3000 req/s peak, and 800M SQL queries per day, 8500/s peak. At such scale being a monolith works for them. This and this are a good read.

This blog post is an excerpt from my Web Application and Software Architecture 101 course, where I discuss web architecture in great detail. I wish I had a product like this in the initial years of my career.

Folks, in the next write-up, I will discuss Modular monolith. I am Shivang. You can catch me on LinkedIn here. If you found the content helpful, I request you to share it with your network for better reach. Until the next blog post. Cheers!