Chapter 1: Escaping Monolithic Hell

Many successful applications start as a single, unified codebase. Over time, this codebase grows large and hard to manage. This section explains how that happens.

The architecture of the FTGO application

FTGO is an online food-delivery platform. It began as a monolithic application — one deployable unit containing all the business logic. The server-side code handles REST API requests, web pages, and integration with external services such as payment and messaging.

At its core, the FTGO monolith has a hexagonal architecture. Business logic sits in the center, surrounded by adapters that connect it to the outside world (databases, message brokers, REST clients).

The benefits of the monolithic architecture

When an application is small, the monolithic architecture has clear advantages:

• Simple to develop — IDEs and tools work well with one codebase.
• Easy to test — you can write end-to-end tests that cover the whole application.
• Easy to deploy — copy one file to a server.
• Easy to scale horizontally — run multiple copies behind a load balancer.

Living in monolithic hell

As the application grows over months and years, the codebase becomes very large. Development slows down. Teams step on each other's code. Deployments become risky. The application becomes difficult to understand, and fixing a bug in one area can break something in another. This state is called monolithic hell.

Whether you are a developer, architect, CTO, or VP of Engineering, monolithic hell is a problem you will likely face. This book provides a structured approach — a pattern language — to adopt the microservice architecture successfully.

Even if you are already working with microservices, the patterns help you solve recurring design problems in communication, data management, and deployment.

The book covers a broad set of topics needed to design, build, and operate microservices:

• How to decompose an application into services (by business capability or DDD subdomain).
• How services communicate using messaging or remote procedure invocation (REST, gRPC).
• How to manage data consistency across services with Sagas.
• How to query data spread across services using API Composition and CQRS.
• Deployment, observability, testing, and security patterns.

The microservice architecture structures an application as a set of small, loosely coupled services. Each service is independently deployable and focuses on one business capability.

Scale cube and microservices

The Scale Cube is a three-dimensional model for scaling applications. Each axis represents a different strategy.

Axis	Strategy	What it does
X-axis	Horizontal cloning	Run multiple identical copies of the application behind a load balancer. Improves capacity but does not reduce complexity.
Y-axis	Functional decomposition	Split the application into separate services by function. This is what defines the microservice architecture.
Z-axis	Data partitioning	Each instance handles a subset of data (e.g., by customer ID). Complements X and Y axes.

Microservices as a form of modularity

In a monolith, modularity is enforced by code conventions and packages — but nothing stops a developer from breaking module boundaries. In a microservice architecture, each service is a separate process with a well-defined API. You cannot accidentally call another service's internal code. This hard boundary enforces modularity much better than code conventions alone.

Each service has its own database

In a microservice architecture, each service owns its private database. No other service can access it directly. This is the Database per Service pattern.

Because services cannot share a database, you need new patterns for consistency and querying:

• Saga — coordinates multi-service transactions without a shared database transaction.
• API Composition — gathers data from multiple services to answer a query.
• CQRS (Command Query Responsibility Segregation) — maintains a read-optimized view of data from multiple services.

The FTGO microservice architecture

In the microservice version of FTGO, the monolith is split into services such as Order Service, Restaurant Service, Delivery Service, Kitchen Service, and Accounting Service. Each service owns its data and exposes a REST or messaging API.

An API Gateway sits in front of all services. It routes requests from external clients (web, mobile) to the correct internal service. A related pattern, Backend for Frontend (BFF), creates a separate gateway for each client type.

Comparing the microservice architecture and SOA

Service-Oriented Architecture (SOA) and the microservice architecture both organize applications into services. However, they differ in important ways.

Aspect	SOA	Microservices
Communication	Heavy protocols (ESB, WS-*, SOAP)	Lightweight protocols (REST, gRPC, messaging)
Data	Shared global database is common	Database per service
Service size	Larger, enterprise-wide services	Smaller services focused on one capability

Benefits of the microservice architecture

• Enables continuous delivery and deployment — each service can be deployed independently, reducing risk and speeding up releases.
• Small, maintainable services — each service is small enough for one team to understand and own.
• Independently scalable — you only scale the services that need more resources, instead of scaling the entire application.
• Better fault isolation — a failure in one service does not crash the whole system (when combined with patterns like Circuit Breaker).
• Technology flexibility — different services can use different languages, frameworks, or databases.
• Enables autonomous teams — teams can develop, test, and deploy their services without waiting for other teams.

Drawbacks of the microservice architecture

• Distributed system complexity — inter-service communication, partial failures, and network latency add complexity.
• Data consistency challenges — without a single database transaction, you must use patterns like Saga.
• Harder to query across services — joins across databases are not possible; you need API Composition or CQRS.
• Deployment complexity — managing many services requires automation and tooling.
• Risk of distributed monolith — if services are incorrectly decomposed or tightly coupled, you get the worst of both worlds.

Aspect	Monolithic	Microservices
Simplicity	Simple to develop, test, deploy early on	More moving parts from the start
Scalability	Scale entire app (wasteful)	Scale individual services
Team autonomy	Teams share the same codebase	Teams own independent services
Data consistency	Single database transaction (ACID)	Requires Sagas for cross-service consistency
Deployment	One unit to deploy	Many units; needs automation
Fault isolation	One bug can crash everything	Failures contained per service

A pattern language is an organized collection of patterns that solve related problems. The microservice architecture pattern language groups patterns into several categories that cover the full lifecycle of building microservices.

Microservice architecture is not a silver bullet

Microservices solve many problems, but they also introduce new ones. There is no single correct answer — every decision involves tradeoffs. The pattern language helps you navigate these tradeoffs by showing which patterns solve which problems, and what new issues each pattern may create.

Patterns and pattern languages

A pattern is a reusable solution to a problem that occurs in a specific context. Each pattern describes the problem, the forces at play, the solution, and the resulting consequences (both positive and negative). Patterns often have relationships: one pattern's consequence may be a problem solved by another pattern.

A pattern language groups these patterns into a structured collection. It shows alternatives, dependencies, and chains of patterns that work together.

Overview of the Microservice architecture pattern language

The pattern language is organized into the following groups. Each group addresses a different concern.

Decomposition patterns

These patterns decide how to split an application into services.

Communication patterns

Services need to talk to each other. Two main styles exist.

Reliable communication also requires handling failures:

Service discovery patterns

Services need to find each other on the network. A Service Registry is a database of service instance locations.

Pattern	How it works
Client-side Discovery	The client queries the Service Registry and picks an instance to call.
Server-side Discovery	The client sends a request to a router/load balancer, which queries the registry.
Self Registration	Each service registers itself in the registry on startup.
3rd-party Registration	An external component (e.g., deployment platform) registers services in the registry.

External API patterns

Data management patterns

The Database per Service pattern creates challenges for consistency and querying.

To reliably publish domain events from a service's database, you can use:

Deployment patterns

Pattern	Description
Single Service per Host	Each service instance runs on its own host. Variants: Service-per-Container, Service-per-VM.
Multiple Services per Host	Several service instances share one host. Simpler but less isolated.
Serverless Deployment	Deploy service code as functions. The platform handles scaling and infrastructure.
Service Deployment Platform	An automated platform (e.g., Kubernetes) that manages all deployment patterns.

Observability patterns

With many services running, you need visibility into the system. Observability patterns work together to give you that visibility.

• Health Check API — each service exposes an endpoint that reports if it is healthy.
• Log Aggregation — collect logs from all services into a central, searchable store.
• Distributed Tracing — track a request as it flows through multiple services.
• Exception Tracking — automatically capture and group exceptions across services.
• Application Metrics — collect and monitor service-level metrics (latency, error rate, throughput).
• Audit Logging — record user actions for compliance and debugging.

Testing patterns

Testing microservices in isolation requires new approaches.

• Consumer-driven Contract Test — the consumer defines the contract, and the provider verifies it passes.
• Consumer-side Contract Test — tests that verify a consumer correctly uses a provider's API.
• Service Component Test — tests a service in isolation using stubs for its dependencies.

Cross-cutting and security patterns

Technology alone is not enough. You also need the right team structure and development process to succeed with microservices.

Software development and delivery organization

The microservice architecture enables small, autonomous teams — often called two-pizza teams (small enough to be fed by two pizzas). Each team owns one or more services end-to-end: development, testing, deployment, and operations.

Software development and delivery process

Autonomous two-pizza teams enable Continuous Delivery and Deployment (DevOps). Each team can push changes to production frequently and safely because they only deploy their own service, not the entire application.

The human side of adopting microservices

Moving from a monolith to microservices is not just a technical change — it is also an emotional transition for people. Roles change, responsibilities shift, and familiar workflows disappear.

The concepts in this chapter connect to each other in chains. Understanding these relationships helps you see how patterns depend on one another.