When to use Monolithic Architecture

Published in

Design Microservices Architecture with Patterns & Principles

6 min readFeb 14, 2023

In this article, we are going to learn When to use and When NOT to use Monolithic Architecture.

By this article, we are going to understand the best use cases of Monolithic Architecture and Design our E-Commerce application with Monolithic Architecture.

I have just published a new course — Design Microservices Architecture with Patterns & Principles.

Introduction — Monolithic Architecture

A monolithic architecture is a traditional approach to software development. Monolithic architecture is an architectural pattern of designing and developing a complete application as a single unit.

Even monolithic architecture has lots of disadvantages, if you are building small application, still monolithic architecture is one of the best architecture that you can apply for your projects. Because, In many ways, monolithic apps are straightforward. They’re straightforward to:

Build
Test
Deploy
Troubleshoot
Scale vertically (scale up) is very easy and fast.

It is simple to develop relative to microservices where skilled developers are required in order to identify and develop the services. It is Easier to deploy as only a single jar/war file is deployed.

So When to use Monolithic Architecture ?

Here you can find list of use cases about When to use Monolithic Architectures:

Small team at Founding Stage

If you are a startup and your team is small like 2 to 5 members, you don’t need to deal with the complexity of the microservices architecture. A monolith can meet all your business requirements and provide to focus on your business instead of technology chooses so there is no emergency to follow the hype and start with high-overhead microservices architecture.

Simple application with Predictable Scale and Complexity

If you develop a simple application which isn’t include complex business logics and isn’t required superior scalability and flexibility, then its good to work with Monolithic architectures. So that means If your application doesn’t require advanced scalability and the complexity is manageable, then a monolith architecture is the best option to start.

Proof of Concept and Quick Launch

If you’re building a proof of concept, like testing a new idea on market, that means your new products will pivot and evolve a lot over time, when you figure out what will be useful to your users.

Also this will provide to launch your application as soon as possible, Monolithic Architecture works well when you don’t want to spend so much time at initially and validate your business idea. For that reason, a monolith is good fit that is allows for rapid product iteration. By this way you can test your idea and decide to pivot or end up with project very fast.

No Microservices Expertise

If your team has no prior experience with microservices architecture, that will really hard to ship your application effectively and timely. Because Microservices require profound expertise to work well and bring business value. If you want to start a microservices application from scratch with no technical expertise in it, most probably, you will end up with fail or stuck at some point with spending lots of resources and time.

Request per Second and Acceptable Latency

For example, lets see our example e-commerce application. If we don’t need to expect hundreds of request, we can scale it vertically which is scaling up, that means upgrading existing server. By this way we can avoid the problems of network latency and security are relatively less if we compare with the microservices architecture. Please see the table:

As you can see in the table, we will start a small e-commerce application that get only 2K concurrent user and gets 500 request per second. And we will design our e-commerce architecture as per these expected volumes. After that, when our business grow and grow, it will required more resources to accommodate bigger request counts, and we will see how we can evolve our architecture as per these numbers.

So if you don’t expect any growth of your customer base, so we should pick the Monolithic architecture. Even we expect growth of our users to 500K or millions of users, its good to start simple and evolve step by step. As you can see that we understand When to use Monolithic Architecture.

When to use and When NOT to use Monolithic Architecture ?

Monolithic architecture is a good choice when:

The application is relatively simple and has limited functional requirements.
The development team is small and familiar with the entire codebase.
There is a need for a faster development cycle and quicker time to market.
The application has limited scalability requirements, and can run on a single server.

Monolithic architecture should not be used when:

The application is expected to grow significantly over time, and may need to scale horizontally to accommodate increased traffic.
The application has complex and diverse functional requirements, and may need to be divided into smaller, more manageable components.
The development team is large and distributed, and may benefit from a more modular architecture that allows for easier collaboration and code sharing.
The application requires a high level of availability and must minimize downtime during deployments and updates.

In these cases, it may be more appropriate to use a microservices architecture or another architectural style that better suits the specific requirements of the project and organization. The choice of architecture should be based on a thorough assessment of the project’s goals, requirements, and constraints, as well as an understanding of the trade-offs and limitations of each architecture style.

Design Monolithic Architecture — E-Commerce App

If we design e-commerce application with Monolithic architecture, you can see the image below:

There is a big single Monolithic Application Server and one big relational databases.

Design Microservice Architecture — E-Commerce App

If we design e-commerce application with Microservice architecture, you can see the image below:

Product microservice can use NoSQL document database Shopping Cart microservice can use NoSQL key-value pair database and Order microservice can use Relational database as per microservice data storage requirements.

What’s Next ?

Step by Step Design Architectures w/ Course