Pattern: Monolithic Architecture

Context

You are developing a business-critical enterprise application. You need to deliver changes rapidly, frequently and reliably - as measured by the DORA metrics - in order for your business to thrive in today’s volatile, uncertain, complex and ambiguous world. Consequently, your engineering organization is organized into small, loosely coupled, cross-functional teams as described by Team Topologies. Each team delivers software using DevOps practices as defined by the DevOps handbook. In particular, it practices continuous deployment. The team delivers a stream of small, frequent changes that are tested by an automated deployment pipeline and deployed into production.

A team is responsible for one or more subdomains. A subdomain is an implementable model of a slice of business functionality, a.k.a. business capability. It consists of business logic, which consists of business entities (a.k.a. DDD aggregates) that implement business rules, and adapters, which communicate with the outside world. A Java-based subdomain, for example, consists of classes organized into packages that’s compiled into a JAR file.

The subdomains implement the application’s behavior, which consists of a set of (system) operations. An operation is invoked in one of three ways: synchronous and asynchronous requests from clients; events published by other applications and services; and the passing of time. It mutates and queries business entities in one or more subdomains.

Problem

How to organize the subdomains into one or more deployable/executable components?

Forces

There are five dark energy forces:

• Simple components - simple components consisting of few subdomains are easier to understand and maintain than complex components
• Team autonomy - a team needs to be able to develop, test and deploy their software independently of other teams
• Fast deployment pipeline - fast feedback and high deployment frequency are essential and are enabled by a fast deployment pipeline, which in turn requires components that are fast to build and test.
• Support multiple technology stacks - subdomains are sometimes implemented using a variety of technologies; and developers need to evolve the application’s technology stack, e.g. use current versions of languages and frameworks
• Segregate by characteristics - e.g. resource requirements to improve scalability, their availability requirements to improve availability, their security requirements to improve security, etc.

There are five dark matter forces:

• Simple interactions - an operation that’s local to a component or consists of a few simple interactions between components is easier to understand and troubleshoot than a distributed operation, especially one consisting of complex interactions
• Efficient interactions - a distributed operation that involves lots of network round trips and large data transfers can be too inefficient
• Prefer ACID over BASE - it’s easier to implement an operation as an ACID transaction rather than, for example, eventually consistent sagas
• Minimize runtime coupling - to maximize the availability and reduce the latency of an operation
• Minimize design time coupling - reduce the likelihood of changing services in lockstep, which reduces productivity

Solution

Design an architecture that structures the application as a single deployable/executable component that uses a single database. The component contains all of the application’s subdomains. Since there’s a single component, all operations are local.

Example

Let’s imagine that you are building an e-commerce application that takes orders from customers, verifies inventory and available credit, and ships them. The application consists of several components including the StoreFrontUI, which implements the user interface, along with some backend services for checking credit, maintaining inventory and shipping orders.

The application is deployed as a single monolithic application. For example, a Java web application consists of a single WAR file that runs on a web container such as Tomcat. A Rails application consists of a single directory hierarchy deployed using either, for example, Phusion Passenger on Apache/Nginx or JRuby on Tomcat. You can run multiple instances of the application behind a load balancer in order to scale and improve availability.

Resulting context

Benefits

Since the application consists of a single component and all operations are local this solution has a number of benefits. Specifically, the dark energy forces are resolved as follows:

• Simple interactions - all interactions are generally easier to understand and troubleshoot. However, interactions between subdomains could potentially be complex.
• Efficient interactions - interactions are typically more efficient since all communication is local.
• Prefer ACID over Base - operations can be implemented as ACID transactions (usually)
• Minimize runtime coupling - there’s no runtime coupling between components
• Minimize design time coupling - these’s no design time coupling between components. There can, however, be design time coupling between subdomains within the monolith.

Drawbacks

This solution has a number of (potential) drawbacks. Specifically, an architecture might fail to resolve the dark energy forces:

• Simple components - since there’s only a single component it is potentially difficult to understand and maintain due its size and complexity
• Team autonomy - there’s potentially less team autonomy since all teams are contributing to the same code base and they need to coordinate their work more often
• Fast deployment pipeline - the deployment pipeline is potentially slow since there’s a single large application that needs to be built and tested
• Multiple technology stacks - the application uses a single technology stack, which might not be ideal for all subdomains. Also, if the application is large upgrading the technology stack might be very time consuming
• Segregate by characteristics - there’s no possibility of segregating subdomains by their characteristics, which might reduce scalability, availability, security etc

These drawbacks become more severe as the application grows in size and complexity and the number of teams developing it increases.

Issues

A key challenge with the monolithic architecture is minimizing the potential drawbacks, especially as the application grows in size and complexity and the number of teams developing it increases. There are a few solutions that can reduce some of the drawbacks:

• Increase maintainability and team autonomy by modularizing the monolith. Instead of the traditional layered architecture, the subdomains are organized into vertical slices consisting of presentation, business and persistent logic.

• Accelerate the deployment pipeline by

  • apply physical design principles to the modular monolith in order to reduce build time coupling
  • implementing an automated merge queue
  • using a build tool that supports incremental building and testing
  • parallelizing and clustering the build and test steps.

Related patterns

The microservice architecture is an alternative pattern that addresses the limitations of the monolithic architecture.

Known uses

Well known internet services such as Netflix, Amazon.com and eBay initially had a monolithic architecture. Most web applications developed by the author prior to 2012 had a monolithic architecture.

Chris offers numerous other resources for learning the microservice architecture.

Example microservices applications

Want to see an example? Check out Chris Richardson's example applications. See code