When I started my job at Paytm, an e-commerce and payment gateway company in India, it was a startup company. We began with monolithic application architecture because there was only two of us there at the time. Many startups begin application development by following monolithic application architecture due to the small size of their team. Monolithic architecture doesn't give you big operational overhead costs, and they often have just one massive codebase.

A monolithic application is a single artifact that includes the interfaces of all layers. For example, a database might have several tables and DAO classes, a client-side UI that includes HTML pages and JavaScript, and a server-side application. This server-side application has to handle HTTP requests, process business logic using service classes, retrieve and update data from the database, exchange messages with other systems, and return responses in an HTML/JSON/XML format. A monolithic application often has a massive codebase which includes all of the aforementioned. As a developer, if you want to make any changes to this massive codebase, you have to build and deploy another updated version of the server-side application.

In a server-side application, you have to focus on development to provide support to a variety of different clients, such as desktop browsers, mobile browsers, and native mobile applications, including Android and iOS. A monolithic application must, therefore, have a complete code in order to support a variety of different clients. Let's discuss an example of a monolithic architecture pattern.

Suppose we are working on an e-commerce application that provides an online bookshop portal. It takes orders from customers, verifies the availability of the ordered book, places an order, and ships the ordered book to the customer. To build this application, we have to create several modules.

These include a Shop Front UI module, which provides a user interface to customers, and backend services, such as an Account Service, a Book Service, an Order Service, a Shipping Service, and so on. These services have various responsibilities, including verifying the customer, checking the availability of books, placing an order, and shipping the order.

All of these modules will be deployed as a single monolithic application either as a WAR file or JAR file. A Java web application as a WAR file runs on a web container such as Tomcat. This web application serves all HTTP requests that come from various clients, such as desktop or mobile browsers. The request comes first to Apache or Nginx and then to Tomcat.

You can also create multiple instances of this monolithic application to handle millions or billions of requests, or include a load balancer to scale and improve availability.

The following diagram illustrates the architectural design of a monolithic application:

As you can see in the preceding diagram, all modules of this traditional web application, such as Shop Front UI, Account Service, Order Service, Book Service, and Shipping Service, are single artifacts in the Tomcat container. This monolithic application has a massive codebase that includes all modules. If you introduce new modules to this application, you have to make changes to the existing code and then deploy the artifact with a different code to the Tomcat server.

Server-side application developers can include the following components in the architecture design:

• Presentation: This layer handles HTTP requests and responds with HTML, JSON, or XML
• Business logic: This is the business logic written into services such as the Account Service or Customer Service
• Data access: These objects are responsible for accessing the database for business logic
• Application integration: This component is responsible for integrating the application with other external services via messaging or the REST API

In monolithic application architecture, we place such components as a single artifact in the server-side application. This application architecture means that a new team member can be introduced to the application easily due to the close nature of the team. However, when you have to change the application due to scalability or availability requirements, you have to run multiple copies of the application on multiple machines.

Monolithic application architecture can be made logically modular by dividing it into different layers according to the types of components. All modules and different layers are packaged and deployed as a single artifact monolithic application. Let's now move on and look at the benefits of monolithic application architecture.

The monolithic solution has the following benefits:

• Simple to develop: Monolithic applications are very simple to develop because current development tools and IDEs support the development of monolithic applications
• Simple to test: As we have already discussed, monolithic applications have all of their modules in a single artifact, so you can easily carry out end-to-end testing by simply running the application either manually or with Selenium
• Simple to deploy: A monolithic application is a single artifact, so you can easily deploy it to the server as a WAR file
• Simple to scale: You can easily achieve scaling by copying the single artifact of the application to multiple running machines and setting up a load balancer behind the monolithic application

As you can see, monolithic applications have numerous benefits. They also have several disadvantages, which we will discuss shortly, but let's first have a look at the situations in which monolithic applications are useful.

Monolithic architecture can be used in the following situations:

• In the foundation stage of projects – most of the time, big, successful applications start with monolithic application architecture
• When building an unproven product or proof of concept
• When your development team is less experienced

Despite the benefits of monolithic application architecture, there are also a few disadvantages.

Monolithic application architecture can sometimes have the following disadvantages:

• A monolithic application has a large codebase, which can intimidate developers, especially those who are new to the team. The application can be difficult to understand and modify. As a result, development is typically quite slow.
• The application is large and complex, which makes it difficult to fully understand and make changes quickly and correctly.
• The impact of a change is usually not very well understood, which leads to carrying out extensive, additional manual testing.
• The architecture can be difficult to scale when different modules have conflicting resource requirements.
• Monolithic applications aren't very reliable; a bug in any module can bring down the whole application.
• They are not very adept at adopting new technologies. Since changes in frameworks or languages will affect an entire application, it is extremely expensive both time-wise and cost-wise.

Let’s now discuss which software development processes are better with monolithic architecture.

For a monolithic application, traditional software development processes, such as waterfall processes, are most suitable. This is because a monolithic application usually has large teams working on a single deployment artifact.

As we have discussed, a monolithic application is a single artifact, built as a single unit. This means that it handles the HTTP requests and executes business logic using DAOs to retrieve data from the underlying database at the server-side. However, with a monolithic application, if any changes are made to the application, another version of the entire application will need to be built. Fortunately, this is where the microservice architecture pattern can come to the rescue.