The full stack landscape is further complicated by the different web architecture patterns commonly used these days. The widely used web application architecture patterns today can be broadly classified into two patterns—monolithic architecture and microservice architecture, the latter of which has become mainstream (fashionable) in recent years.

A monolithic architecture is the most widely used pattern for web applications because of its simplicity to develop and deploy. Though the actual moving parts will differ from application to application, the general pattern remains the same. In general, a monolithic web application can do the following:

• It can support different clients, such as desktop/mobile browsers and native desktop/mobile applications.
• It can expose APIs for third-party consumption.
• It can integrate with other applications over REST/SOAP web services or message queues.
• It can handle HTTP requests, execute business logic, access databases, and exchange data with other systems.
• It can run on web application containers, such as Tomcat and JBoss.
• It can be scaled vertically by increasing the power of the machines it runs on or scaled horizontally by adding additional instances behind load balancers.

An example of a typical monolithic web application architecture would be as follows: Let's imagine an online hotel reservation system that takes online reservation orders from customers, verifies the room availability, verifies the payment option, makes the reservation, and notifies the hotel. The application consists of several layers and components, including a client-side app—which builds a nice, rich user interface—and several other backend components responsible for managing the reservations, verifying the payment, notifying customers/hotels, and so on.

The application will be deployed as a single monolithic web application archive (WAR) file that runs on a web application container such as Tomcat, and will be scaled horizontally by adding multiple instances behind an Apache web server acting as a load balancer. Take a look at the following diagram:

The advantages of a monolithic web application architecture are as follows:

• It is simpler to develop, as the technology stack is uniform throughout all layers.
• It is simpler to test, as the entire application is bundled in a single package, making it easier to run integration and end-to-end tests.
• It is simpler and faster to deploy, as you only have one package to worry about.
• It is simpler to scale, as you can multiply the number of instances behind a load balancer to scale it out.
• It requires a smaller team to maintain the application.
• The team members share more or less the same skill set.
• The technical stack is simpler and, most of the time, is easier to learn.
• Initial development is faster, thereby making the time to market shorter.
• It requires a simpler infrastructure. Even a simple application container or JVM will be sufficient to run the application.

The disadvantages of a monolithic web application architecture are as follows:

• Components are tightly coupled together, resulting in unwanted side effects, such as changes to one component causing a regression in another.
• It becomes complex and huge as time passes, resulting in slow development turnaround. New features will take more time to develop and refactoring existing features will be more difficult because of tight coupling.
• The entire application needs to be redeployed whenever any change is made.
• It is less reliable because of tightly coupled modules. A small issue with any service might break the entire application.
• Newer technology adoption is difficult as the entire application needs to be migrated. Incremental migration is not possible most of the time, which means that many monolithic applications end up having an outdated technology stack after some years.
• Critical services cannot be scaled individually, resulting in increased resource usage. As a result, the entire application will need to be scaled.
• Huge monolith applications will have a higher start up time and higher resource usage in terms of CPU and memory.
• Teams will be more interdependent and it will be challenging to scale the teams.

The microservice architecture has gained momentum in recent years and is gaining popularity in large-scale web application development because of its modularity and scalability. Microservice architecture can offer almost all the features of a monolith that we saw in the previous section. Additionally, it offers many more features and flexibility and so is often considered a superior choice for complex, large-scale applications. Unlike the monolithic architecture, it's quite difficult to generalize the microservice architecture as it could vary heavily depending on the use case and implementation. But they do (generally) share some common traits, which are as follows:

• Microservice components are loosely coupled. Components can be developed, tested, deployed, and scaled independently without disrupting other components.
• Components need not be developed using the same technology stack. This means that a single component can choose its own technology stack and programming language.
• They often utilize advanced features such as service discovery, circuit breaking, and load balancing.
• Microservice components are mostly lightweight and perform a specific functionality. For example, an authentication service will only care about authenticating a user into the system.
• It often has an extensive monitoring and troubleshooting setup.

An example of a microservice web application architecture would be as follows: Let's imagine a huge online e-commerce system where customers can go through categories of merchandise, list their favorites, add items to a shopping cart, make and track orders, and so on. The system has inventory management, customer management, multiple payment modes, order management, and so on. The application consists of several modules and components, including a UI gateway application, which builds a nice, rich user interface and also handles user authentication and load balancing, and several other backend applications responsible for managing the inventory, verifying the payment, and managing orders. It also has performance monitoring and automatic failover for services.

The application will be deployed as multiple executable WAR files in Docker containers hosted by a cloud provider. Take a look at the following diagram:

The advantages of a microservice web application architecture are as follows:

• Loosely coupled components resulting in better isolation, which means that they are easier to test and faster to start up.
• Faster development turnaround and better time to market for new features, and existing features can be easily refactored.
• Services can be deployed independently, making the application more reliable and making patching easier.
• Issues, such as a memory leak in one of the services, are isolated and will not bring down the entire application.
• Technology adoption is easier, as components can be independently upgraded with incremental migration, making it possible to have a different stack for each component.
• More complex and efficient scaling models can be established. Critical services can be scaled more effectively. Infrastructure is used more efficiently.
• Individual components will start up faster, making it possible to parallelize and improve overall startup for large systems.
• Teams will be less dependent on each other. This is best suited for agile teams.

The disadvantages of a microservice web application architecture are as follows:

• It is more complex in terms of the overall stack as different components might have different technology stacks, forcing the team to invest more time in keeping up with them.
• It is difficult to perform end-to-end tests and integration tests as there are more moving parts in the stack.
• The entire application is more complex to deploy as there are complexities with containers, orchestration, and virtualization involved.
• Scaling is more efficient, but it is also more complex, as it would require advanced features, such as service discovery and DNS routing.
• It requires a larger team to maintain the application, as there are more components and more technologies involved.
• Team members share varying skill sets based on the component they work on, making replacements and knowledge sharing harder.
• Applications with many microservices and different teams managing different services creates more organizational challenges.
• The technical stack is complex and, most of the time, it is harder to learn.
• Initial development time will be higher, making the time to market longer.
• It requires a complex infrastructure. Most often, it will require containers (Docker), orchestration (Kubernetes), and multiple JVM or app containers to run on.
• To effectively manage distributed systems, you need to set up monitoring, distributed tracing, service discovery, and so on. These are not easy to set up and require additional components to be run which will produce overhead and additional costs.