Monolithic architecture is the traditional unified model for the design of a software program.

Monolithic, in this context,

means "composed all in one piece." According to the Cambridge Dictionary, the adjective monolithic also means both
"too large" and "unable to be changed."

In software development, a monolithic architecture model is one where a single codebase is used to perform multiple
functions in an application. Also, each component and its associated components in the application must all be present
for code to be executed or compiled and for the software to run.

Key features and components of monolithic applications

Most monolithic applications have the following characteristics:

Single-tiered. This means that multiple components are combined into one large application. Consequently, the
applications tend to have large codebases, which can be cumbersome to update and manage over time.
Self-contained and unified. They are independent from other applications.
Single codebase. If one component of the program needs to be updated, other elements might also require
rewriting, and the whole application has to be recompiled, tested and deployed.
Single database. They can use a relational database management system as a single data source.

Monolithic applications can include some or all of these components:

Authorization. To authorize a user and allow them to use the application.

Presentation. To handle HTTP requests and respond with Hypertext Markup Language, Extensible Markup
Language or JavaScript Object Notation.
Business logic. The underlying business rules that determine which functionalities and features should be
included in the application.
Database layer. Includes the data access objects that reach out to the application's database to achieve a specific
goal.
Notification module. Enables the application to send automated communications to users, such as through
email.

What is an example of monolithic architecture?

To understand monolithic architecture, let's take an example of a banking application. Here's how it works:

The application website authorizes customers.

It logs them in to their account.
Once they are in, they can check their account balance, download statements, transfer money to other accounts
and perform other actions.

Several components are involved in this process, including the customer-facing user interface, plus back-end services
for user authentication, authorization and customer actions.

If the application is monolithic, it is built and deployed as a single, unified, self-contained unit, regardless of how a
customer uses it or where they access it from -- desktop, mobile device, etc. Also, it remains tightly coupled, and all the
various components and modules are directly connected to each other. This means that if changes are needed for any
one component, code changes are required for all other affected components as well.
Many well-known applications started off as monolithic and then adopted what is known as the microservices approach
over time. These include the following apps:

Spotify.
Netflix.
Facebook.
Instagram.
Uber.

That said, some applications have gone back to the monolithic approach after transitioning to a microservices
architecture. One well-known example is Amazon Prime.

Some applications have remained true to their monolithic roots since inception. Examples include the WordPress
content management system and Linux operating system kernel.

Lots of organizations find it advantageous to move away from monolithic architectures toward
the adoption of microservices architectures.

Advantages of monolithic architecture

Many applications are still created using the monolithic development paradigm because it offers several benefits.

For example, some monolithic programs might have better throughput and response times than modular, microservices-
based applications, especially if the number of threads and users is small. They might also be easier to test and debug
because they are composed of fewer elements and therefore involve fewer testing variables and scenarios.

The monolithic architecture simplifies development during the early stages of the software development lifecycle
(SDLC). Deployment can be further simplified by copying the packaged application to a server. A single codebase
simplifies logging, configuration management and application performance monitoring. Finally, multiple copies of the
application can be placed behind a load balancer to enable horizontal scaling.
 The single codebase of monolithic software architecture includes tasks such as configuration
management and other development concerns.

Disadvantages of monolithic architecture

Despite its benefits, monolithic architecture also presents several disadvantages:

1. The use of a single codebase means that a code update to one component of the application necessitates
updates to all related components. This process can be time-consuming, which can delay application development
and deployment, as well as limit the agility and speed of development teams. This drawback becomes especially
significant for complex products or large teams.
2. Some applications have a large codebase, which can be difficult to understand. Poor understanding hinders
developers from making required code modifications to meet changing business or technical requirements. As
requirements evolve or become more complex, it becomes even harder to correctly implement changes without
hampering code quality and application performance.
3. Following each update, developers must compile the entire codebase and redeploy the full application rather than
just the part that was updated. This makes continuous or regular deployments difficult, affecting the application's
and team's agility.
4. The application's size can increase startup and response times.
5. Different parts of the application might have conflicting resource requirements. This makes it harder to find the
resources required to scale the application.
6. Reliability is a concern with monolithic software. A bug in any one component can potentially bring down the entire
application. Considering the previous banking application example: A memory leak in the user authorization
module could end up making the entire application unavailable to users.
7. Finally, monolithic applications are not easily adaptable to new technologies due to their size and complexity, as
well as the effort and costs involved in potential redevelopment. This can be a serious hurdle for small or budget-
constrained organizations, leaving them unable to take advantage of a new programming language or framework.
What is the difference between monolithic and microservices
architectures?
In monolithic architecture, the various components of the application are interdependent and controlled from a single
codebase. Even small changes could affect large parts of the codebase. It's also time-consuming to make these
changes because the entire codebase needs to be updated, and the entire application must be rebuilt and redeployed.

In contrast, a microservices architecture (MSA) consists of loosely coupled components, with each component based on
a specific business logic and meant to accomplish a specific function. Code changes are easy when only a relevant part
of the codebase needs to be updated. Also, the components that are changed can be individually tested and reliably
deployed without the risk of bringing down the entire application. Components are also independently deployable,
meaning that the entire application does not have to be redeployed for the changes to take effect.

Today, many organizations are moving away from monolithic architecture and adopting MSA because it offers multiple
advantages:

It supports modular applications, where any single module, such as a microservice, can be changed independently
without affecting the other parts and without creating unanticipated changes within those elements.
Modular programs are more adaptable to continual or iterative development and popular Agile practices compared
with monolithic programs.
They are also more scalable because each component gets its own resources that can be scaled independently of
other components to match evolving requirements or demands.
Modules communicate with each other through application programming interfaces and well-defined interfaces.
Each module has its own database, which can improve application startup speed.
It speeds up release cycles in that developers can push out updates as frequently as needed.

When to use monolithic vs. microservices architecture

At the beginning of the SDLC, it might be easier to go with a monolithic architecture. The approach is also suited for
simple, lightweight applications or applications with a small number of expected users.

For more complex applications with frequent code changes expected, this monolithic approach is not suitable. In such
situations, a microservices architecture might be the better choice. The microservices approach is also more suitable in
the following cases:

The application is meant to be scalable, easy to test and easy to maintain.

There might be a need to independently deploy individual features or components.
Continuous or frequent deployment is required.
Teams need the freedom to work with new technologies, languages or tools.

Explore architecting beyond microservices and monoliths, see when not to use microservices, read about ways to
survive the challenges of monolithic architectures and use these steps to break monoliths into microservices.