Pattern: Monolithic Architecture

pattern   application architecture  


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.


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


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


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.


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


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 been 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.


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.


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.

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

Known uses

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

pattern   application architecture  

Copyright © 2024 Chris Richardson • All rights reserved • Supported by Kong.

About is brought to you by Chris Richardson. Experienced software architect, author of POJOs in Action, the creator of the original, and the author of Microservices patterns.

New workshop: Architecting for fast, sustainable flow

Enabling DevOps and Team Topologies thru architecture

DevOps and Team topologies are vital for delivering the fast flow of changes that modern businesses need.

But they are insufficient. You also need an application architecture that supports fast, sustainable flow.

Learn more and register for my September 2024 online workshops....


I help organizations improve agility and competitiveness through better software architecture.

Learn more about my consulting engagements, and training workshops.

LEARN about microservices

Chris offers numerous other resources for learning the microservice architecture.

Get the book: Microservices Patterns

Read Chris Richardson's book:

Example microservices applications

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

Virtual bootcamp: Distributed data patterns in a microservice architecture

My virtual bootcamp, distributed data patterns in a microservice architecture, is now open for enrollment!

It covers the key distributed data management patterns including Saga, API Composition, and CQRS.

It consists of video lectures, code labs, and a weekly ask-me-anything video conference repeated in multiple timezones.

The regular price is $395/person but use coupon WURMXAJV to sign up for $95 (valid until July 19th, 2024). There are deeper discounts for buying multiple seats.

Learn more

Learn how to create a service template and microservice chassis

Take a look at my Manning LiveProject that teaches you how to develop a service template and microservice chassis.

Signup for the newsletter

BUILD microservices

Ready to start using the microservice architecture?

Consulting services

Engage Chris to create a microservices adoption roadmap and help you define your microservice architecture,

The Eventuate platform

Use the platform to tackle distributed data management challenges in your microservices architecture.

Eventuate is Chris's latest startup. It makes it easy to use the Saga pattern to manage transactions and the CQRS pattern to implement queries.

Join the microservices google group