Software Architecture Patterns

SECOND EDITION

Understanding Common Architectural Styles and

When to Use Them

Mark Richards
Software Architecture Patterns
by Mark Richards
Copyright © 2022 O’Reilly Media, Inc. All rights reserved.
Printed in the United States of America.
Published by O’Reilly Media, Inc., 1005 Gravenstein Highway North,
Sebastopol, CA 95472.
O’Reilly books may be purchased for educational, business, or sales promotional
use. Online editions are also available for most titles (http://oreilly.com). For
more information, contact our corporate/institutional sales department: 800-998-
9938 or [email protected].

Acquisitions Editor: Melissa Duffield

Development Editor: Shira Evans

Production Editor: Kristen Brown

Copyeditor: Sonia Saruba

Interior Designer: David Futato

Cover Designer: Randy Comer

Illustrator: Rob Romano

February 2015: First Edition

July 2022: Second Edition

Revision History for the Second Edition

2022-07-29: First Release
The O’Reilly logo is a registered trademark of O’Reilly Media, Inc. Software
Architecture Patterns, the cover image, and related trade dress are trademarks of
O’Reilly Media, Inc.
While the publisher and the author have used good faith efforts to ensure that the
information and instructions contained in this work are accurate, the publisher
and the author disclaim all responsibility for errors or omissions, including
without limitation responsibility for damages resulting from the use of or
reliance on this work. Use of the information and instructions contained in this
work is at your own risk. If any code samples or other technology this work
contains or describes is subject to open source licenses or the intellectual
property rights of others, it is your responsibility to ensure that your use thereof
complies with such licenses and/or rights.
978-1-098-13427-3
[LSI]
Chapter 1. Introduction

It’s all too common for developers to start coding an application without a
formal architecture in place. This practice usually results in ill-defined
components, creating what is commonly referred to as a big ball of mud. These
architectures are generally tightly coupled, brittle, difficult to change, and lack a
clear vision or direction. It’s also very difficult to determine the architectural
characteristics of applications lacking a well-defined architectural style. Does the
architecture scale? What are the performance characteristics of the application?
How easy is it to change the application or add new features? How responsive is
the architecture?
Architecture styles help define the basic characteristics and behavior of an
application. Some architecture styles naturally lend themselves toward highly
scalable systems, whereas other architecture styles naturally lend themselves
toward applications that allow developers to respond quickly to change.
Knowing the characteristics, strengths, and weaknesses of each architecture style
is necessary to choose the one that meets your specific business needs and goals.
A lot has happened in software architecture since 2015 when the first edition of
this report was published. Both microservices and event-driven architecture have
gained in popularity, and developers and architects have found new techniques,
tools, and ways of designing and implementing these architecture styles. Also,
the widespread use of domain-driven design has led to a better understanding of
how architectures are structurally partitioned, and how that partitioning can
impact the design and implementation of a system. The second edition of the
report addresses both of these advances.
The second edition also includes other significant enhancements, along with
more information about the intersection of architecture and data, and an
expanded analysis section at the end of each chapter. These new sections provide
you with better guidelines for when to use (and not to use) each architecture
presented in this report.
Another change you’ll notice in the second edition is the use of the term
architecture style rather than architecture pattern for the architectures described
in this report. This distinction helps alleviate some of the confusion surrounding
the differences between, say, event-driven architecture—an architecture style—
and something like CQRS (Command Query Responsibility Segregation), which
is an architecture pattern.
An architecture style, such as the ones presented in this report, describe the
macro structure of a system. Architecture patterns, on the other hand, describe
reusable structural building block patterns that can be used within each of the
architecture styles to solve a particular problem. Take, for example, the well
known CQRS pattern, which describes the structural separation between read
and write operations to a database or eventing system (for example, separate
services and databases for read operations and write operations). This
architecture pattern could be applied to any of the architecture styles described in
this report to optimize database queries and updates.
Architecture patterns, in turn, differ from design patterns (such as the Builder
design pattern) in that an architecture pattern impacts the structural aspect of a
system, whereas a design pattern impacts how the source code is designed. For
example, you can use the Builder design pattern as a way to implement the
CQRS architecture pattern, and then use the CQRS pattern as a building block
within a microservices architecture. Figure 1-1 shows this hierarchical
relationship among the three terms and how they interrelate with each other to
build software systems.
Figure 1-1. Architecture styles can be composed of architecture patterns, which in turn can be composed of
design patterns

Design patterns and architecture patterns are typically combined to form a

complete solution. Architecture styles act in the same way—they can also be
combined when building software solutions to form a complete solution. Hybrid
architecture styles are common in the real world because not every architecture
style can solve every business problem. Common architecture style hybrids
include event-driven microservices (events between microservices), space-based
microservices (processing units implemented as microservices), and even an
event-driven microkernel architecture (events between the core system and
remote plug-in components). Although forming hybrids is a common practice, it
is vital to understand individual architecture styles and their corresponding
strengths and weaknesses before combining them.
The goal of this updated second edition report remains the same as the first
edition: to help senior developers and architects understand some of the more
common architecture styles, how they work, when to use them, and when not to
use them. This will help to not only expand your knowledge of architecture, but
will also help you make the right architecture choice for your systems.
Chapter 2. Architectural
Structures and Styles

Architecture styles allow you to use existing and well-known structures that
support certain architectural characteristics (also known as nonfunctional quality
attributes, system quality attributes, or “-ilities”). They not only provide you
with a head start on defining an architecture for a given system, but they also
facilitate communication among developers, architects, quality assurance testers,
operations experts, and even in some cases, business stakeholders.

Architecture Classification
Architecture styles are classified as belonging to one of two main architectural
structures: monolithic (single deployment unit) and distributed (multiple
deployment units, usually consisting of services). This classification is important
to understand because as a group, distributed architectures support much
different architecture characteristics than monolithic ones. Knowing which
classification of architecture to use is the first step in selecting the right
architecture for your business problem.

Monolithic Architectures
Monolithic architecture styles (as illustrated in Figure 2-1) are generally much
simpler than distributed ones, and as such are easier to design and implement.
These single deployment unit applications are fairly inexpensive from an overall
cost standpoint. Furthermore, most applications architected using a monolithic
architecture style can be developed and deployed much more quickly than
distributed ones.
 Figure 2-1. Monolithic architectures are single deployment units

While cost and simplicity are the main strong points of a monolithic architecture,
operational characteristics such as scalability, fault tolerance, and elasticity are
its weak points. A fatal error (such as an out of memory condition) in a
monolithic architecture causes all of the functionality to fail. Furthermore, mean
time to recovery (MTTR) and mean time to start (MTTS) are usually measured
in minutes, meaning that once a failure does occur, it takes a long time for the
application to start back up. These long startup times also impact scalability and
elasticity. While scalability can sometimes be achieved through load balancing
multiple instances of the application, the entire application functionality must
scale, even if only a small portion of the overall application needs to scale. This
is not only inefficient, but unnecessarily costly as well.
Examples of monolithic architecture styles include the layered architecture
(described in Chapter 3), the modular monolith, the pipeline architecture, and the
microkernel architecture (described in Chapter 4).

Distributed Architectures
As the name suggests, distributed architectures consist of multiple deployment
units that work together to perform some sort of cohesive business function. In
today’s world, most distributed architectures consist of services, although each
distributed architecture style has its own unique formal name for a service.
Figure 2-2 illustrates a typical distributed architecture.
 Figure 2-2. Distributed architectures consist of multiple deployment units

The superpowers of distributed architectures usually fall within operational

characteristics—things like scalability, elasticity, fault tolerance, and in some
cases, performance. Scalability in these architecture styles is typically at the
individual service level, as is elasticity. Hence, MTTS and MTTR are much
smaller than with a monolithic application, measured usually in seconds (and in
some cases milliseconds) rather than minutes.
Distributed architectures are well suited for supporting high levels of fault
tolerance. If one service fails, in many cases other services can continue to
service requests as if no fault happened. Services that do fail can recover very
quickly—so quickly that at times an end user sometimes doesn’t even know the
service had a fatal error.
Agility (the ability to respond quickly to change) is often another superpower of
distributed architectures. Because application functionality is divided into
separately deployed units of software, it is easier to locate and apply a change,
the testing scope is reduced to only the service that is impacted, and deployment
risk is significantly reduced because only the service impacted is typically
deployed.
Unfortunately, with all those good features come some bad features as well.
Distributed architectures are plagued with what are known as the fallacies of
distributed computing, a set of eight things we believe to be true about networks
and distributed computing, but are in fact false. Things like “the network is
reliable,” “bandwidth is infinite,” and “latency is zero” all make distributed
architectures not only hard to keep deterministic, but also hard to make
completely reliable. Networks do fail, bandwidth is not infinite, and latency is
not zero. These things are as real today as they were back in the late ’90s when
they were coined.
In addition to the eight fallacies of distributed computing, other difficulties arise
with distributed architectures. Distributed transactions, eventual consistency,
workflow management, error handling, data synchronization, contract
management, and a host of other complexities are all part of the world of
distributed architecture. To top it off, all this complexity usually means much
more cost from an overall initial implementation and ongoing maintenance cost
than monolithic architectures. Suddenly, all of those great superpowers don’t
sound so great anymore when you consider all the trade-offs of distributed
architectures.
Examples of distributed architectures include event-driven architecture
(described in Chapter 5), the ever-popular microservices architecture (described
in Chapter 6), service-based architecture, service-oriented architecture, and
space-based architecture (described in Chapter 7).

Which One Should I Choose?

When choosing between a monolithic versus a distributed architecture, one
question to first ask yourself is if the system you are creating has different sets of
architecture characteristics that must be supported. In other words, does the
entire system need to scale and support high availability, or only parts of the
system? Systems that contain multiple sets of different architecture
characteristics generally call for a distributed architecture. A good example of
this is customer-facing functionality requiring support for scalability,
responsiveness, availability, and agility, and an administrative or backend
processing functionality that doesn’t need any of those characteristics.
Simple systems or websites usually warrant the simpler and more cost-effective
monolithic architecture style, whereas more complex systems that perform
multiple business functions usually warrant more complex distributed
architectures. Similarly, the “need for speed,” the need for high volumes of
scalability, and the need for high fault tolerance are all characteristics that lend
themselves toward distributed architectures.

Architecture Partitioning
Besides being classified as either monolithic or distributed, architectures can
also be classified by the way the overall structure of the system is partitioned.
Architectures, whether they are monolithic or distributed, can be either
technically partitioned or domain partitioned. The following sections describe
the differences between these partitioning structures and why it’s important to
understand them.

Technical Partitioning
Technically partitioned architectures have the components of the system
organized by technical usage. The classic example of a technically partitioned
architecture is the layered (n-tiered) architecture style (see Chapter 3). In this
architecture style, components are organized by technical layers; for example,
presentation components that have to do with the user interface, business layer
components that have to do with business rules and core processing, persistence
layer components that interact with the database, and the database layer
containing the data for the system.
Notice in Figure 2-3 that the components of any given domain are spread across
all of these technical layers. For example, the customer domain functionality
resides in the presentation layer as customer screens, the business layer as
customer logic, the presentation layer as customer queries, and the database
layer as customer tables. Manifested as namespaces, these components would be
organized as follows: app.presentation.customer,
app.business.customer, app.persistence.customer, and so on.
Notice how the second node in the namespace specifies the technical layering,
and that the customer node is spread across those layers.
 Figure 2-3. In a technically partitioned architecture, components are grouped by their technical usage

Technically partitioned architectures are useful if a majority of your changes are

isolated to a specific technical area in the application. For example, if you are
constantly changing the look and feel of your user interface without changing the
corresponding business rules, change is isolated to only one part of the
architecture (in this case, the presentation layer). Similarly, if your business rules
are constantly changing but there is no impact to the data layer or presentation
layer, changes are isolated to the business layer of the architecture with no
impact to other parts of the system.
However, imagine implementing a new requirement to add an expiration data to
items for customer wish lists in a technically partitioned architecture. This type
of change is considered a domain-based change (not a technical usage one), and
impacts all of the layers of the architecture. To implement this change, you
would need to add a new column to the wish list table in the database layer,
change the corresponding SQL in the persistence layer, add the corresponding
business rules to components in the business layer, change the contracts between
the business and presentation layer, and finally change the screens in the
presentation layer. Depending on the size of the system and the team structure,
this simple change might involve the coordination of three to four different
teams.
Examples of technically partitioned architectures include the layered architecture
(Chapter 3), microkernel architecture (Chapter 4), pipeline architecture, event-
driven architecture (Chapter 5), and space-based architecture (Chapter 7).
Microkernel architecture is particularly interesting in that it’s the only
architecture style that can be either technically partitioned or domain partitioned
depending on how the plug-in components are used. For example, when the
plug-in components are used as adapters or special configuration settings, it
would be considered technically partitioned.

Domain Partitioning
Unlike technically partitioned architectures, components in domain partitioned
architectures are organized by domain areas, not technical usage. This means
that all of the functionality (presentation, business logic, and persistence logic) is
grouped together for each domain and subdomain area in separate areas of the
application. For domain partitioned architectures, components might be
manifested through a namespace structure such as app.customer,
app.shipping, app.payment, and so on. Notice that the second node
represents the domain rather than a technical layer. As a matter of fact, domains
can be further organized into technical layering if so desired, which might take
the form app.customer.presentation, app.customer.business,
and so on. Notice that even though the customer domain logic may be organized
by technical usage, the primary structure (represented as the second node of the
namespace) is still partitioned by domain. Figure 2-4 shows a typical example of
a domain partitioned architecture.
Domain partitioned architectures have grown in popularity over the years in part
due to the increased use and acceptance of domain-driven design, a software
modeling and analysis technique coined by Eric Evans. Domain-driven design
places an emphasis on the design of a domain rather than on complex workflows
and technical components. This approach allows teams to collaborate closely
with domain experts and focus on one key part of the system, thus developing
software that closely resembles that domain functionality.
 Figure 2-4. In a domain partitioned architecture, components are grouped by domain area

The clear advantage of domain partitioning within an architecture is that changes

to a particular domain or subdomain are self-contained within a specific area of
the system, allowing teams to pinpoint exactly the area of the system that
requires the change.
Coming back to our implementation of expiration data for a customer’s wish list
items, with domain partitioning the changes in code are isolated to only one
small part of the system, making this type of change much more effective than
with technical partitioning. Here, for example, changes would be isolated to the
namespace starting with app.customer.wishlist, meaning that
presentation logic, business logic, and persistence logic are all within the same
area of the system. Maintenance is easier, testing is easier, and deployment is
much less risky when these types of changes are done.
Examples of domain partitioned architectures include the microkernel
architecture (Chapter 4), microservices architecture (Chapter 6), modular
monolith architecture, and service-based architecture. As indicated earlier,
microkernel architecture can be either technically partitioned or domain
partitioned. If the plug-in components are used to extend the application by
adding functionality, then it would be considered a domain partitioned
architecture.

Which One Should I Choose?

The choice between a technically partitioned architecture and a domain
partitioned architecture is an important one. The overall structure of the
architecture must be aligned not only with the team structure, but also with the
nature of the types of changes expected in the system in order to be successful
and effective.
Technically partitioned architectures (whether monolithic or distributed) are well
suited when your overall team structure is organized by those same technical
usage areas. For example, if your development teams are organized as teams of
user interface developers, backend developers, and database developers,
technically partitioned architectures would be a good fit because the team
structure matches the technical layers of the architecture. Technically partitioned
architectures are also a natural fit when most of your expected changes are
aligned with technical layers (for example, multiple user interfaces, changes to
the look and feel of the system, swapping out one database for another, and so
on).
If you are embarking on a new system and using a domain-driven design
approach, then you should in turn consider a domain partitioned architecture.
Also, domain partitioned architectures are a great fit if your teams are organized
into cross-functional teams with specialization—in other words, single teams
that are aligned with specific domain functionality and contain user interface
developers, backend developers, and database developers all on the same
physical team.
Domain partitioned architectures are also a good choice when you expect most
of your changes to be domain scoped rather than technical usage scoped. This
allows for much better agility (the ability to respond quickly to change) than
with technically partitioned architectures. However, be careful when choosing a
domain partitioned architecture if you have lots of changes to technical usage
layers. For example, swapping out one database type for another or changing the
entire user interface framework would be a difficult and time-consuming task in
a domain partitioned architecture.
Chapter 3. Layered Architecture

The most common architecture style is the layered architecture, otherwise

known as the n-tier architecture. This style is the de facto standard for most
applications because it aligns with traditional IT team structures where teams are
organized by technical domains (such as presentation teams, backend
development teams, database teams, and so on). Because it is so widely known
by most architects, designers, and developers, the layered architecture is a
natural choice for most business application development efforts. However, like
all architecture styles, it has its strengths and weaknesses and is not always
suitable for some systems.

Description
Components within the layered architecture style are organized into horizontal
layers, each performing a specific role within the application (such as
presentation logic, business logic, persistence logic, and so on). Although the
number of layers may vary, most layered architectures consist of four standard
layers: presentation, business, persistence, and database (see Figure 3-1). In
some cases, the business layer and persistence layer are combined into a single
business layer, particularly when the persistence logic (such as SQL) is
embedded within the business layer components. Thus, smaller applications may
have only three layers, whereas larger and more complex business applications
may contain five or more layers.
 Figure 3-1. The layered architecture style is a technically partitioned architecture

Each layer of the layered architecture style has a specific role and responsibility
within the application. For example, a presentation layer is responsible for
handling all user interface and browser communication logic, whereas a business
layer is responsible for executing specific business rules associated with the
request. Each layer in the architecture forms an abstraction around the work that
needs to be done to satisfy a particular business request. For example, the
presentation layer doesn’t need to know about how to get customer data; it only
needs to display that information on a screen in a particular format. Similarly, the
business layer doesn’t need to be concerned about how to format customer data
for display on a screen or even where the customer data is coming from; it only
needs to get the data from the persistence layer, perform business logic against
the data (e.g., calculate values or aggregate data), and pass that information up to
the presentation layer.
Layers are usually manifested through a namespace, package structure, or
directory structure (depending on the implementation language used). For
example, customer functionality in a business layer might be represented as
app.business.customer, whereas in the presentation layer, customer
logic would be represented as app.pre⁠sentation.customer. In this
example, the second node of the namespace represents the layer, whereas the
third node represents the domain component. Notice, that the third node of the
namespace (customer) is duplicated for all of the layers—this is indicative of
a technically partitioned architecture, where the domain is spread across all
layers of the architecture.
One of the powerful features of the layered architecture style is the separation of
concerns among components. Components within a specific layer deal only with
logic that pertains to that layer. For example, components in the presentation
layer deal only with presentation logic, whereas components residing in the
business layer deal only with business logic. This type of component
classification makes it easy to build effective roles and responsibility models into
your architecture, and makes it easy to develop, test, govern, and maintain
applications using this architecture style when well-defined component
interfaces and contracts are used between layers.

Key Concepts
In this architecture style, layers can be either open or closed. Notice in Figure 3-
2 that each layer in the architecture is marked as being closed. A closed layer
means that as a request moves from layer to layer, it must go through the layer
right below it to get to the next layer below that one. For example, a request
originating from the presentation layer must first go through the business layer
and then to the persistence layer before finally hitting the database layer.
So why not allow the presentation layer direct access to either the persistence
layer or database layer? After all, direct database access from the presentation
layer is much faster than going through a bunch of unnecessary layers just to
retrieve or save database information. The answer to this question lies in a key
concept known as layers of isolation.
The layers of isolation concept means that changes made in one layer of the
architecture generally don’t impact or affect components in other layers: the
change is isolated to the components within that layer, and possibly another
associated layer (such as a persistence layer containing SQL). If you allow the
presentation layer direct access to the persistence layer, then changes made to
SQL within the persistence layer would impact both the business layer and the
presentation layer, thereby producing a very tightly coupled application with lots
of interdependencies between components. This type of architecture then
becomes brittle and very hard and expensive to change.
Figure 3-2. With closed layers, the request must pass through that layer
The layers of isolation concept also means that each layer is independent of the
other layers, thereby having little or no knowledge of the inner workings of other
layers in the architecture. To understand the power and importance of this
concept, consider a large refactoring effort to convert the presentation
framework from the angular.js framework to the react.js framework. Assuming
that the contracts (e.g., model) used between the presentation layer and the
business layer remain the same, the business layer is not affected by the
refactoring and remains completely independent of the type of user interface
framework used by the presentation layer. The same is true with the persistence
layer: if designed correctly, replacing a relational database with a NoSQL
database should only impact the persistence layer, not the presentation or
business layer.
While closed layers facilitate layers of isolation and therefore help isolate
change within the architecture, there are times when it makes sense for certain
layers to be open. For example, suppose you want to add a shared services layer
to an architecture containing common service functionality accessed by
components within the business layer (e.g., data and string utility classes or
auditing and logging classes). Creating a services layer is usually a good idea in
this case because architecturally it restricts access to the shared services to the
business layer (and not the presentation layer). Without a separate layer, there is
nothing that architecturally restricts the presentation layer from accessing these
common services, making it difficult to govern this access restriction.
In the shared services layer example, this layer would likely reside below the
business layer to indicate that components in this services layer are not
accessible from the presentation layer. However, this presents a problem in that
the business layer shouldn’t be required to go through the services layer to get to
the persistence layer. This is an age-old problem with the layered architecture,
and is solved by creating open layers within the architecture.
As illustrated in Figure 3-3, the services layer in this case should be marked as
open, meaning requests are allowed to bypass this layer and go directly to the
layer below it. In the following example, since the services layer is open, the
business layer is allowed to bypass it and go directly to the persistence layer,
which makes perfect sense.
 Figure 3-3. With open layers, the request can bypass the layer below it

Leveraging the concept of open and closed layers helps define the relationship
between architecture layers and request flows, and provides designers and
developers with the necessary information to understand the various layer access
restrictions within the architecture. Failure to document or properly
communicate which layers in the architecture are open and closed (and why)
usually results in tightly coupled and brittle architectures that are very difficult to
test, maintain, and deploy.

Examples
To illustrate how the layered architecture works, consider a request from a
business user to retrieve customer information for a particular individual, as
illustrated in Figure 3-4. Notice the arrows show the request flowing down to the
database to retrieve the customer data, and the response flowing back up to the
screen to display the data.
 Figure 3-4. An example of the layered architecture

In this example, the customer information consists of both customer data and
order data (orders placed by the customer). Here, the customer screen is
responsible for accepting the request and displaying the customer information. It
does not know where the data is, how it is retrieved, or how many database
tables must be queried to get the data.
Once the customer screen receives a request to get customer information for a
particular individual, it then forwards that request to the customer delegate
module in the presentation layer. This module is responsible for knowing which
modules in the business layer can process that request, and also how to get to
that module and what data it needs (the contract). The customer object in the
business layer is responsible for aggregating all of the information needed by the
business request (in this case to get customer information).
Next, the customer object module invokes the customer DAO (data access
object) module in the persistence layer to get customer data, and the order DAO
module to get order information. These modules in turn execute SQL statements
to retrieve the corresponding data and pass it back up to the customer object in
the business layer. Once the customer object receives the data, it aggregates the
data and passes that information back up to the customer delegate, which then
passes that data to the customer screen to be presented to the user.

Considerations and Analysis

The layered architecture is a well-understood and general-purpose architecture
style, making it a good starting point for most applications, particularly when
you are not sure what architecture style is best suited for your application.
However, there are a couple of things to consider from an architecture standpoint
before choosing this style.
The first thing to watch out for is what is known as the architecture sinkhole
anti-pattern. This anti-pattern describes the situation where requests flow
through multiple layers of the architecture as simple pass-through processing
with little or no logic performed within each layer. For example, assume that the
presentation layer responds to a request from the user to retrieve customer data.
The presentation layer passes the request to the business layer, which simply
passes the request to the persistence layer, which then makes a simple SQL call
to the database layer to retrieve the customer data. The data is then passed all the
way back up the stack with no additional processing or logic to aggregate,
calculate, or transform the data.
Every layered architecture will have at least some scenarios that fall into the
architecture sinkhole anti-pattern. The key, however, is to analyze the percentage
of requests that fall into this category. The 80-20 rule is usually a good practice
to follow to determine whether or not you are experiencing the architecture
sinkhole anti-pattern. It’s typical to have around 20 percent of the requests as
simple pass-through processing and 80 percent of the requests having some
business logic associated with them. However, if you find that this ratio is
reversed and a majority of your requests are simple pass-through processing, you
might want to consider making some of the architecture layers open, keeping in
mind that while it will be faster, it will be more difficult to control change due to
the lack of layer isolation.
The layered architecture is still just as viable today as it was in the old days
when it was first introduced. While more modern analysis and design approaches
such as domain-driven design have given developers and architects a way to
think about a problem from a domain perspective rather than a technical one,
there are still times when technically partitioned architectures (such as the
layered architecture) are more suitable.

When to Consider This Style

The layered architecture is good to consider if the project or initiative has
significant budget or time constraints. Because the layered architecture is
generally considered a monolithic architecture style, it does not have the
complexities of a distributed architecture in terms of remote access, contract
management, and the complications resulting from the fallacies of distributed
computing described in the previous chapter. Also, most developers and
architects are familiar with the layered architecture, making it easier to
understand and implement.
Another reason to consider the layered architecture is when a majority of your
changes are isolated to specific layers within the application. For example,
changes isolated to only business rules that don’t impact the user interface,
changes involving only the user interface look-and-feel, migration to a new user
interface framework, and even migration to a new type of database are all
isolated to a specific layer in the architecture, making it easier to isolate the
components impacted by the change.
Because the layered architecture is a technically partitioned architecture, it’s a
good fit if the team structure is also technically partitioned. In other words, if
your overall team structure is organized as teams of presentation (UI)
developers, backend developers, shared services teams, database teams, and so
on, this aligns well to the overall partitioning of this architecture style
(presentation layer, business layer, persistence layer, and so on). This alignment
is known as Conway’s Law.

When Not to Consider This Style

While there are good reasons to consider the layered architecture as described in
the prior section, unfortunately there are even more reasons not to consider the
layered architecture.
The first reason not to consider the layered architecture is if you have high
operational concerns for your application—things like scalability, elasticity,
fault tolerance, and performance. Because layered architectures lend themselves
toward a monolithic architecture, applications built using this architecture style
are generally difficult to scale. While the layered architecture can sometimes
scale by splitting the layers into separate physical deployments and/or creating
separate instances of the application in multiple virtual machines, it becomes
very expensive and inefficient because 100% of the application functionality
must scale. In addition, the layered architecture is not very fault-tolerant—a fatal
crash in any part of the application brings down the entire application
functionality.
Another reason to avoid the layered architecture is when a majority of your
changes are at a domain level rather than a technical one. Suppose you are tasked
with adding an expiration date to the customer’s “My Movie List” within a
movie streaming application (movies a customer has queued up to watch later).
This new feature would first require a change to the database schema, then a
change to the SQL in the persistence layer, then a change to the business rules
and contracts in the business layer (such as how long before expiration, what to
do when a movie in your list expires, and so on), and finally a change to the
presentation layer to display the expiration date beside each movie in the list.
In analyzing this relatively simple change to the “My Movie List” functionality,
notice how every layer of the architecture is impacted and requires change. In
large systems with technically partitioned teams, this might even involve the
coordination of multiple teams (the UI team, backend team, database team, and
so on) to make this change. This not only impacts overall agility (the ability to
respond quickly to change), but also impacts the overall time and effort involved
in making this change.
Lastly, if your overall team structure is organized by cross-functional domain-
based teams (single teams that have UI, backend, and database expertise focused
on a particular domain within the application), the layered architecture is not a
good fit because the technically partitioned architecture structure is not aligned
with the domain partitioned team structure.

Architecture Characteristics
The chart illustrated in Figure 3-5 summarizes the overall capabilities
(architecture characteristics) of the layered architecture in terms of star ratings.
One star means the architecture characteristic is not well supported, whereas five
stars means it’s well suited for that particular architecture characteristic.
Figure 3-5. Architecture characteristics star ratings for the layered architecture
Chapter 4. Microkernel
Architecture

The microkernel architecture style is a flexible and extensible architecture that

allows a developer or end user to easily add additional functionality and features
to an existing application in the form of extensions, or “plug-ins,” without
impacting the core functionality of the system. For this reason, the microkernel
architecture is sometimes referred to as a “plug-in architecture” (another
common name for this architecture style). This architecture style is a natural fit
for product-based applications (ones that are packaged and made available for
download in versions as a typical third-party product), but is also common for
custom internal business applications. In fact, many operating systems
implement the microkernel architecture style, hence the origin of this style’s
name.

Topology
The microkernel architecture style consists of two types of architecture
components: a core system and plug-in modules. Application logic is divided
between independent plug-in modules and the basic core system, providing
extensibility, flexibility, and isolation of application features and custom
processing logic. Figure 4-1 illustrates the basic topology of the microkernel
architecture style.
The core system of this architecture style can vary significantly in terms of the
functionality it provides. Traditionally, the core system contains only the
minimal functionality required to make the system operational (such as the case
with older IDEs such as Eclipse), but it can also be more full featured (such as
with web browsers like Chrome). In either case, the functionality in the core
system can then be extended through the use of separate plug-in modules.
 Figure 4-1. Microkernel architecture style

Plug-in modules are standalone, independent components that contain

specialized processing, additional features, adapter logic, or custom code that is
meant to enhance or extend the core system to provide additional business
capabilities. Generally, plug-in modules should be independent of other plug-in
modules and not be dependent on other plug-ins to function. It’s also important
in this architecture style to keep communication between plug-ins to a minimum
to avoid confusing dependency issues.
The core system needs to know which plug-in modules are available and how to
get to them. One common way of implementing this is through a plug-in
registry. The registry contains information about each plug-in module, including
its name, contract details, and remote access protocol details (depending on how
the plug-in is connected to the core system). For example, a plug-in for tax
software that flags items as a high risk for triggering an audit might have a
registry entry that contains the name of the service (AuditChecker), the contract
details (input data and output data), and the contract format (XML). In cases
where the contracts and access protocol are standard within the system, the
registry might only contain the name of the plug-in module and an interface
name for how to invoke that plug-in.
Plug-in modules can be connected to the core system in a variety of ways.
Traditionally, plug-ins are implemented as separate libraries or modules (such as
JAR and DLL files) connected in a point-to-point fashion (such as a method call
via an interface). These separate modules can then be managed through
frameworks such as OSGi (Open Service Gateway Initiative), Java Modularity,
Jigsaw, Penrose, and Prism or .NET environments. When plug-ins are deployed
in this manner, the overall deployment model is that of a monolithic (single
deployment) architecture. Techniques such as dropping a file in a particular
directory and restarting the application are common for the microkernel
architecture when using point-to-point plug-ins. Some applications using the
previously listed frameworks can also support runtime plug-in capabilities for
adding or changing plug-ins without having to restart the core system.
Alternatively, plug-ins can also be implemented as part of a single consolidated
codebase, manifested simply through a namespace or package structure. For
example, a plug-in that might perform an assessment of a specific electronic
device (such as an iPhone 12) for an electronics recycling application might have
the namespace app.plugin.assessment.iphone12. Notice that the
second node of this namespace specifies that this code is a plug-in, specifically
for the assessment of an iPhone 12 device. In this manner, the code in the plug-in
is separate from the code in the core system.
Plug-in modules can also be implemented as remote services, and accessed
through REST or messaging interfaces from the core system. In this case, the
microkernel architecture would be considered a distributed architecture. All
requests would still need to go through the core system to reach the plug-in
modules, but this type of configuration allows for easier runtime deployment of
the plug-in components, and possibly better internal scalability and
responsiveness if multiple plug-ins need to be invoked for a single business
request.

Examples
A classic example of the microkernel architecture is the Eclipse IDE.
Downloading the basic Eclipse product provides you little more than a fancy
editor. However, once you start adding plug-ins, it becomes a highly
customizable and useful product for software development. Internet browsers are
another common example using the microkernel architecture: viewers and other
plug-ins add additional capabilities that are not otherwise found in the basic
browser (the core system). As a matter of fact, many of the developer and
deployment pipeline tools and products such as PMD, Jira, Jenkins, and so on
are implemented using microkernel architecture.
The examples are endless for product-based software, but what about the use of
the microkernel architecture for small and large business applications? The
microkernel architecture applies to these situations as well. Tax software,
electronics recycling, and even insurance applications can benefit from this
architecture style.
To illustrate this point, consider claims processing in a typical insurance
company (filing a claim for an accident, fire, natural disaster, and so on). This
software functionality is typically very complicated. Each jurisdiction (for
example, a state in the United States) has different rules and regulations for what
is and isn’t allowed in an insurance claim. For example, some jurisdictions allow
for a free windshield replacement if your windshield is damaged by a rock,
whereas other jurisdictions do not. This creates an almost infinite set of
conditions for a standard claims process.
Not surprisingly, most insurance claims applications leverage large and complex
rules engines to handle much of this complexity. However, these rules engines
can grow into a complex big ball of mud where changing one rule impacts other
rules, or requires an army of analysts, developers, and testers just to make a
simple rule change. Using the microkernel architecture style can mitigate many
of these issues.
For example, the stack of folders you see in Figure 4-2 represents the core
system for claims processing. It contains the basic business logic required by the
insurance company to process a claim (which doesn’t change often), but contains
no custom jurisdiction processing. Rather, plug-in modules contain the specific
rules for each jurisdiction. Here, the plug-in modules can be implemented using
custom source code or separate rules engine instances. Regardless of the
implementation, the key point is that jurisdiction-specific rules and processing
are separate from the core claims system and can be added, removed, and
changed with little or no effect on the rest of the core system or other plug-in
modules.

Figure 4-2. Microkernel architecture example of processing an insurance claim

Considerations and Analysis

The microkernel architecture style is very flexible and can vary greatly in
granularity. This style can describe the overarching architecture of a system, or it
can be embedded and used as part of another architecture style. For example, a
particular event processor, domain service, or even a microservice can be
implemented using the microkernel architecture style, even though other services
are implemented in other ways.
This architecture style provides great support for evolutionary design and
incremental development. You can produce a minimal core system that provides
some of the primary functionality of a system, and as the system evolves
incrementally, you can add features and functionality without having to make
significant changes to the core system.
Depending on how this architecture style is implemented and used, it can be
considered as either a technically partitioned architecture or a domain partitioned
one. For example, using plug-ins to provide adapter functionality or specific
configurations would make it a technically partitioned architecture, whereas
using plug-ins to provide additional extensions or additional functionality would
make it more of a domain partitioned architecture.

When to Consider This Style

The microkernel architecture style is good to consider as a starting point for a
product-based application or custom application that will have planned
extensions. In particular, it is a good choice for products where you will be
releasing additional features over time or you want control over which users get
which features.
Microkernel architecture is also a good choice for applications or products that
have multiple configurations based on a particular client environment or
deployment model. Plug-in modules can specify different configurations and
features specific to any particular environment. For example, an application that
can be deployed on any cloud environment might have a different set of plug-ins
that act as adapters to fit the specific services of that particular cloud vendor,
whereas the core system contains the primary functionality and remains
completely agnostic as to the actual cloud environment.
As with the layered architecture style, the microkernel architecture style is
relatively simple and cost-effective, and is a good choice if you have tight
budget and time constraints.

When Not to Consider This Style

All requests must go through the core system, regardless of whether the plug-ins
are remote or point-to-point invocations. Because of this, the core system acts as
the main bottleneck to this architecture, and is not well suited for highly scalable
and elastic systems. Similarly, overall fault tolerance is not good in this
architecture style, again due to the need for the core system as an entry point.
One of the goals of the microkernel architecture is to reduce change in the core
system and push extended functionality and code volatility out to the plug-in
modules, which are more self-contained and easier to test and change. Therefore,
if you find that most of your changes are within the core system and you are not
leveraging the power of plug-ins to contain additional functionality, this is likely
not a good architecture match for the problem you are trying to solve.

Architecture Characteristics
The chart illustrated in Figure 4-3 summarizes the overall capabilities
(architecture characteristics) of the microkernel architecture in terms of star
ratings. One star means the architecture characteristic is not well supported,
whereas five stars means it’s well suited for that particular architecture
characteristic.
Figure 4-3. Architecture characteristics star ratings for the microkernel architecture
Chapter 5. Event-Driven
Architecture

The event-driven architecture style has significantly gained in popularity and use
over recent years, so much so that even the way we think about it has changed.
This high adoption rate isn’t overly surprising given some of the hard problems
event-driven architecture solves, such as complex nondeterministic workflows
and highly reactive and responsive systems. Furthermore, new techniques, tools,
frameworks, and cloud-based services have made event-driven architecture more
accessible and feasible than ever before, and many teams are turning to event-
driven architecture to solve their complex business problems.

Topology
Event-driven architecture is an architecture style that relies on asynchronous
processing using highly decoupled event processors that trigger events and
correspondingly respond to events happening in the system. Most event-driven
architectures consist of the following architectural components: an event
processor, an initiative event, a processing event, and an event channel. These
components and their relationships are illustrated in Figure 5-1.
 Figure 5-1. The main components of event-driven architecture

An event processor (today usually called a service) is the main deployment unit
in event-driven architecture. It can vary in granularity from a single-purpose
function (such as validating an order) to a large, complex process (such as
executing or settling a financial trade). Event processors can trigger
asynchronous events, and respond to asynchronous events being triggered. In
most cases, an event processor does both.
An initiating event usually comes from outside the main system and kicks off
some sort of asynchronous workflow or process. Examples of initiating events
are placing an order, buying some Apple stock, bidding on a particular item in an
auction, filing an insurance claim for an accident, and so on. In most cases,
initiating events are received by only one service that then starts the chain of
events to process the initiating event, but this doesn’t have to be the case. For
example, placing a bid on an item in an online auction (an initiating event) may
be picked up by a Bid Capture service as well as a Bid Tracker service.
A processing event (today usually referred to as a derived event) is generated
when the state of some service changes and that service advertises to the rest of
the system what that state change was. The relationship between an initiating
event and a processing event is one-to-many—a single initiating event typically
spawns many different internal processing events. For example, through the
course of a workflow, a Place Order initiating event may result in an Order
Placed processing event, a Payment Applied processing event, a
Inventory Updated processing event, and so on. Notice how an initiating
event is usually in noun-verb format, whereas a processing event is usually in
verb-noun format.
The event channel is the physical messaging artifact (such as a queue or topic)
that is used to store triggered events and deliver those triggered events to a
service that responds to those events. In most cases initiating events use a point-
to-point channel using queues or messaging services, whereas processing events
generally use publish-and subscribe channels using topics or notification
services.

Example Architecture
To see how all of these components work together in a complete event-driven
architecture, consider the example illustrated in Figure 5-2 where a customer
wants to order a copy of Fundamentals of Software Architecture by Mark
Richards and Neal Ford (O’Reilly). In this case, the initiating event would be
Place Order. This initiating event is received by the Order Placement
service, which then places the order for the book. The Order Placement
service in turn advertises what it did to the rest of the system through a Order
Placed processing event.
Notice in this example that when the Order Placement service triggers the
Order Placed event, it doesn’t know which other services (if any) respond to
this event. This illustrates the highly decoupled, nondeterministic nature of
event-driven architecture.
Continuing with the example, notice in Figure 5-2 that three different services
respond to the Order Placed event: the Payment service, the Inventory
Management service, and the Notification service. These services
perform their corresponding business functions, and in turn advertise what they
did to the rest of the system through other processing events.
 Figure 5-2. Processing a book order using event-driven architecture

One thing in particular to notice about this example is how the Notification
service advertises what it did by generating a Notified Customer
processing event, but no other service cares about or responds to this event. So
why then trigger an event that no one cares about? The answer is architectural
extensibility. By triggering an event, the Notification service provides a
hook that future services can respond to (such as a notification tracking service),
without having to make any other modifications to the system. Thus, a good rule
of thumb with event-driven architecture is to always have services advertise their
state changes (what action they took), regardless if other services respond to that
event. If no other services care about the event, then the event simply disappears
from the topic (or is saved for future processing, depending on the messaging
technology used).

Event-Driven Versus Message-Driven

Is there a difference between an event-driven system and a message-driven
system? It turns out there is, and although subtle, it’s an important difference to
know and understand. Event-driven systems process events, whereas message-
driven systems process messages.
The first difference has to do with the context of what you are sending to the rest
of the system. An event is telling others about a state change or something you
did. Examples of an event include things like “I just placed an order,” or “I just
submitted a bid for an item.” A message, on the other hand, is a command or
request to a specific service. Examples of a message include things like “apply a
payment to this order,” “ship this item to this address,” or “give me the
customer’s email address.” Notice the difference here—with an event, the
service triggering the event has no idea which services (or how many) will
respond, whereas a message is usually directed to a single known service (for
example, Payment).
Another difference between an event and a message is the ownership of the
event channel. With events, the sender owns the event channel, whereas with
messages, the receiver owns the channel. This ownership becomes more
significant when you consider the contract of the event or message. Consider the
example in Figure 5-3 where the Order Placement service is sending out a
Order Placed event that is responded to by the Payment service. In this
case, the sender (Order Placement) owns both the event channel and the
contract. In other words, contract changes would be initiated by the Order
Placement service, and the Payment service and all other services
responding to that event would have to conform and adapt to these changes.

Figure 5-3. With events, the sender owns the event channel and contract

However, with messages in a message-driven system, it’s exactly the opposite—

the receiver owns the message channel. As illustrated in Figure 5-4, the Order
Placement service is telling the Payment service to apply the payment in the
form of a command. In this case, the Payment service owns the message
channel (queue) as well as the message contract. Notice that with message-based
processing, the Order Placement service would need to conform to contract
changes initiated by the Payment service.
 Figure 5-4. With messages, the receiver owns the message channel and contract

The type of event channel artifact is also a distinguishing factor between event-
driven systems and message-driven systems. Typically, event-driven systems use
publish-and-subscribe messaging using topics or notification services when
triggering events, whereas message-driven systems typically use point-to-point
messaging using queues or messaging services when sending messages. That’s
not to say event-driven systems can’t use point-to-point messaging—in some
cases point-to-point messaging is necessary to retrieve specific information from
another service or to control the order or timing of events in a system.

Considerations and Analysis

Because of the asynchronous and decoupled nature of event-driven architecture,
it excels in areas of fault tolerance, scalability, and high performance. It also
provides for excellent extensibility when adding additional features and
functionality. However, while these characteristics are very attractive, especially
for today’s complex systems, there are plenty of reasons not to use event-driven
architecture. The following two sections outline the reasons to consider event-
driven architecture, and more importantly, when to be cautious about using it.

When to Consider This Style

Simply put, event-driven architecture is the architecture of choice for systems
that require high performance, high scalability, and high levels of fault tolerance.
However, there are other reasons to consider this architecture style beyond these
architecture characteristic superpowers.
If the nature of your business processing is reacting to things that are happening
in and around the system (rather than responding to a user request), then this is a
good architecture style to consider. Listen to your business stakeholders—are
they using words like “event,” “triggers,” and “react to something happening”?
If so, then there’s a good chance your business problem matches this architecture
style. Also, ask yourself—am I responding to a user request, or reacting to
something the user did? These are great questions to qualify whether the
business problem matches this architecture style.
Event-driven architecture is also a good choice when you have complex,
nondeterministic workflows that are difficult to model. For decades developers
have been building complex decision trees trying to outline every possible
outcome of a complex workflow, only to continually fail at this fool’s errand.
Systems such as these are sometimes classified as CEP (complex event
processing), something that is managed natively in event-driven architecture.

When Not to Consider This Style

You should not consider this architecture style if most of your processing is
request based. Request-based processing is the typical situation where a user is
requesting data from the database (such as a customer profile) or doing basic
CRUD operations (create, read, update, delete) on entities in the system.
Furthermore, if most of your processing requires synchronous processing where
the user must wait for processing to be complete for a particular request, event-
driven architecture is likely not the right architecture style for you.
Because all processing is eventually consistent in event-driven architecture, this
is not a good architecture style for business problems that require high levels of
data consistency. There is little or no guarantee of when processing will occur in
an event-driven architecture, so if you are expecting certain data to be there at a
certain time, look elsewhere for an architecture style, like service-based, that
helps preserve data consistency.
Another reason to walk away from event-driven architecture and consider a
different architecture style is when you need control over the workflow and
timing of events. Both of these are extremely difficult to manage when doing
asynchronous event processing. For example, imagine the nightmare of
coordinating the following scenario: Event A and Event B must complete
processing before Event C can be triggered, and Event D and Event E
must wait for Event C to finish, but Event D must start processing before
Event E. Good luck managing that mess—you’re better off using orchestrated
service-oriented architecture or orchestrated microservices for that type of
complex coordination.
Error handling is another complexity that causes teams to shy away from event-
driven architecture. Because there is usually no central workflow orchestrator or
controller in event-driven architecture, when errors occur in a service, it’s up to
that service to try to repair the error. Furthermore, because everything is
asynchronous, other actions may have occurred in the workflow for that event.
For example, suppose an Order Placement service triggers an Order
Placed event for a book that a customer ordered. The Notification
service, Payment service, and Inventory service all respond to the event at
the same time. However, suppose the Notification and Payment services
both respond and complete their processing, but the Inventory service throws
an error because there are no more books left when the event is received. Now
what? The customer has already been notified and their credit card has been
charged, but there are no more books left to ship to the customer. Should
payment be reversed? Should another notification be sent to the customer?
Should processing just wait until there’s more inventory? And which service
performs all this error handling logic? Error handing is indeed one of the more
complex aspects of event-driven architecture.

Architecture Characteristics
The chart illustrated in Figure 5-5 summarizes the overall capabilities
(architecture characteristics) of event-driven architecture in terms of star ratings.
One star means the architecture characteristic is not well supported, whereas five
stars means it’s well suited for that particular architecture characteristic.
Figure 5-5. Architecture characteristics star ratings for event-driven architecture
Chapter 6. Microservices
Architecture

Perhaps the biggest change in architecture since 2012 is the introduction of

microservices. This trend-setting architecture style took the world by storm,
similar to what service-oriented architecture (SOA) did back in 2006. Over the
years we’ve learned a lot about this revolutionary (and evolutionary) architecture
style and how it addresses many of the complex problems we face in developing
software solutions. New tools, techniques, frameworks, and platforms have
come about over the years that make microservices easier to design, implement,
and manage. That said, microservices is perhaps one of the most complicated
architecture styles to get right.

Basic Topology
The microservices architecture style is an ecosystem made up of single-purpose,
separately deployed services that are accessed typically through an API gateway.
Client requests originating from either a user interface (usually a microfrontend)
or an external request invoke well-defined endpoints in an API gateway, which
then forwards the user request to separately deployed services. Each service in
turn accesses its own data, or makes requests to other services to access data the
service doesn’t own. The basic topology for the microservices architecture style
is illustrated in Figure 6-1.
 Figure 6-1. The basic topology of the microservices architecture style

Notice that although Figure 6-1 shows each service associated with a separate
database, this does not have to be the case (and usually isn’t). Rather, each
service owns its own collection of tables, usually in the form of a schema that
can be housed in a single highly available database or a single database devoted
to a particular domain. The key concept to understand here is that only the
service owning the tables can access and update that data. If other services need
access to that data, they must ask the owning microservice for that information
rather than accessing the tables directly. The reasoning behind this data
ownership approach is described in detail in “Bounded Context”.
The primary job of the API gateway in microservices is to hide the location and
implementation of the corresponding services that correspond to the API
gateway endpoints. However, the API gateway can also perform cross-cutting
infrastructure-related functions, such as security, metrics gathering, request-ID
generation, and so on. Notice that unlike the enterprise service bus (ESB) in
service-oriented architecture, the API gateway in microservices does not contain
any business logic, nor does it perform any orchestration or mediation. This is
critical within microservices in order to preserve what is known as a bounded
context (detailed further in a moment).

What Is a Microservice?
A microservice is defined as a single-purpose, separately deployed unit of
software that does one thing really, really well. In fact, this is where the term
“microservices” gets its name—not from the physical size of the service (such as
the number of classes), but rather from what it does. Because microservices are
meant to represent single-purpose functions, they are generally fine-grained.
However, this doesn’t always have to be the case. Suppose a developer creates a
service consisting of 312 class files. Would you still consider that service to be a
microservice? In this example, the service actually does only one thing really
well—send emails to customers. Each of the 300+ different emails that could be
sent to a customer is represented as a separate class file, hence the large number
of classes. However, because it does one thing really well (send an email to a
customer), this would in fact be consisted a microservice. This example
illustrates the point that its not about the size of the service, but rather what the
service does.
Because microservices tend to be single-purpose functions, it’s not uncommon to
have hundreds to even thousands of separately deployed microservices in any
given ecosystem or application context. The sheer number of separate services is
what makes microservices so unique. Microservices can be deployed as
containerized services (such as Docker) or as serverless functions.

Bounded Context
As mentioned earlier, each service typically owns its own data, meaning that the
tables belonging to a particular service are only accessed by that service. For
example, a Wishlist service might own its corresponding wishlist tables.
If other services need wish list data, those services would have to ask the
Wishlist service for that information rather than accessing the wishlist
tables directly.
This concept is known as a bounded context, a term coined by Eric Evans in his
book Domain-Driven Design (Addison-Wesley). Within the scope of
microservices, this means that all of the source code representing some domain
or subdomain (such as a wish list for a customer), along with the corresponding
data structures and data, are all encapsulated as one unit, as illustrated in
Figure 6-2.
 Figure 6-2. A bounded context includes the source code and corresponding data for a given domain or
subdomain

This concept is critical for microservices. As a matter of fact, microservices as

an architecture style wouldn’t exist without the notion of a bounded context. To
illustrate this point, imagine 250 microservices all accessing the same set of
tables in a monolithic database. Suppose you make a structural change (such as
dropping a column or table) that 120 of those services access. This change would
require the coordination of modifying, testing, and deploying 120 separate
services at the same time, along with the database change. This is a scenario that
is simply not feasible.
Within microservices, the bounded context not only facilitates architectural
agility (the ability to respond quickly to change), but also manages change
control within a microservices ecosystem. With the bounded context, only the
service that owns the data needs to change when structural data changes happen.
As shown in Figure 6-3, other services requiring access to data within another
bounded context must ask for the data through a separate contract. This contract
is usually a different representation than that of the physical database structure of
the data, thereby usually not requiring a change to other services or the contracts.
 Figure 6-3. The bounded context usually isolates changes to just the service owning the data

Unique Features
Microservices stands apart from all other architecture styles. The three things
that make the microservices architecture style so unique are distributed data,
operational automation, and organizational change.
Microservices is the only architecture style that requires data to be broken up
and distributed across separate services. The reason for this need is the sheer
number of services usually found within a typical microservices architecture.
Without aligning services with their corresponding data within a strict bounded
context, it simply wouldn’t be feasible to make structural changes to the
underlying application data. Because other architecture styles don’t specify the
fine-grained, single-purpose nature of a service as microservices does, those
other architecture styles can usually get by with a single monolithic database.
Although the practice of associating a service with its corresponding data in a
bounded context is one of the main goals of microservices, rarely in the real
world of business applications does this completely happen. While a majority of
services may be able to own their own data, in many cases it’s sometimes
necessary to share data between two or more services. Use cases for sharing data
between a handful of services (two to six) range from table coupling, foreign key
constraints, triggers between tables, and materialized views, to performance
optimizations for data access, to shared ownership of tables between services.
When data is shared between services, the bounded context is extended to
include all of the shared tables as well as all of the services that access that data.
Operational automation is another unique feature that separates microservices
from all other architecture styles, again due to the sheer number of microservices
in a typical ecosystem. It is not humanly possible to manage the parallel testing,
deployment, and monitoring of several hundred to several thousand separately
deployed units of software. For this reason, containerization is usually required,
along with service orchestration and management platforms such as Kubernetes.
This also leads to the requirement of DevOps for microservices (rather than
something that’s “nice to have”). Because of the large number of services, it’s
not feasible to “hand off” services to separate testing teams and release
engineers. Rather, teams own services and the corresponding testing and release
of those services.
This leads to the third thing that distinguishes microservices from all other
architecture styles—organizational change. Microservices is the only
architecture style that requires development teams to be organized into domain
areas of cross-functional teams with specialization (a single development team
consisting of user interface, backend, and database developers). This in turn
requires the identification of service owners (usually architects) within a
particular domain. Testers and release engineers, as well as DBAs (database
administrators), are also usually aligned with specific domain areas so that they
are part of the same virtual team as the developers. In this manner, these “virtual
teams” test and release their own services.

Examples and Use Cases

Applications that are well suited for the microservices architecture style include
those that consist of separate and distinct functions within a business workflow.
A classic example of this is a standard retail-based order entry system. Placing
an order, applying a payment, notifying a customer, managing inventory,
fulfilling the order, shipping the order, tracking the order, sending out surveys,
and data analytics are all separate and distinct functions that work well as
separately deployed microservices.
Another interesting use case for microservices is that of business intelligence
and analytics reporting. Each report, query, data feed, or data analytics can be
developed as a separate microservice, all accessing data within a data lake or
data warehouse. Although with the reporting use case there isn’t a strict bounded
context with the data, this still works as microservices because the underlying
schema structure of a data lake or data warehouse rarely encounters breaking
changes. Rather, older schemas are deprecated and new ones are created to
replace them, helping manage the change control issues usually found with
typical microservices architectures operating on transactional data.

Considerations and Analysis

While microservices is very popular and powerful, it is also perhaps the hardest
architecture style to get right. Service granularity (the size of a service) is one of
the first hard parts of microservices most teams encounter. Single responsibility
principle is unfortunately highly subjective, making it difficult to gain consensus
on the granularity of a service. For example, is a notification service that sends
out emails and SMS texts single purpose, or is notifying a customer via email
single purpose? Other factors, such as code volatility, fault tolerance, scalability
and throughput, and access control, are more objective ways of justifying service
granularity.
Another hard part of the microservices architecture style is how services should
communicate with each other. Should they use asynchronous communication or
synchronous communication? Should you use orchestration for your workflows
between services using an orchestration service to act as a mediator, or
choreography where services directly talk to one another? Each of these
communication choices has numerous trade-offs, making it even more difficult
to answer these questions.
Data is yet another hard part of microservices. If a Wishlist service needs
product information from the Product Catalog service, should it ask for the
data through inter-service communication via REST, cache the data it needs
using an in-memory data grid, expand the wishlist table schema to include
the necessary product data it needs, or simply share the product catalog data?
Again, these choices all have trade-offs, making it difficult to choose the most
appropriate option.
There are many more hard parts about microservices, including distributed
transaction management, contracts, code reuse techniques, migration patterns,
and so on. Fortunately, all of these hard parts and their corresponding trade-offs
are addressed in detail in the book Software Architecture: The Hard Parts by
Neal Ford et al. (O’Reilly).

When to Consider This Style

One of the first considerations in choosing microservices is to take a detailed
look at your application functionality. Is it feasible to break apart your
application functionality into dozens or hundreds of separate and distinct pieces
of functionality that are independent from each other? If so, then this is a good
architecture to consider as this is exactly the shape of microservices.
Applications that require high levels of agility (the ability to respond quickly to
change) are well suited for the microservices architecture style. From a
maintainability standpoint, the bounded context ensures that subdomain
functionality and its corresponding data are bound together, making it easy to
locate and make coding changes. Testing is easier because the testing scope is
usually reduced to a single-purpose service, and as such it’s easier to achieve full
regression testing. Deployment risk is significantly reduced because what is
usually deployed is only a single service. In most cases this can be done through
a hot deploy in the middle of the day as opposed to big-bang deployments over a
weekend.
Microservices is also a good architecture style to consider if you have high fault
tolerance and high scalability needs. Scalability and fault tolerance are both at
the function level in microservices, and because mean time to start (MTTS) and
mean time to recovery (MTTR) are so low (usually measured in hundreds of
milliseconds), microservices is also good for elastic systems.
You should also consider microservices if you have plans for lots of extensibility
in your existing architecture. Adding functionality in microservices is sometimes
simply a matter of creating a service, wrapping it in a container, creating an API
endpoint, and deploying that service. I like to call this technique “drop-in”
functionality. In other words, if you need to add additional features or
functionality to your system, just create a service and drop it into your
ecosystem. Sounds easy, right? Well, in theory it is, but there are lots of reasons
not to use microservices, which are outlined in the next section.

When Not to Consider This Style

While microservices has lots of benefits and superpowers, there are definitely
reasons to avoid this architecture style and consider others instead. The first of
these considerations is the nature of your workflows. Microservices is all about
single-purpose, separately deployed pieces of software that collectively make up
an application. However, if you find that all of that separately deployed
functionality needs to be tied together with complex workflows and lots of inter-
service communication or orchestration, then this is not an architecture you
should consider.
Perhaps one of the biggest factors for not considering microservices relates to
data. If your data is tightly coupled and monolithic in nature (meaning it’s not
feasible to break apart your data into several dozen to several hundred separate
schemas or databases), then run away in the opposite direction of microservices.
By tightly coupled, I mean the data is so interrelated with the functionality that
while you can break apart the functionality of an application into multiple
deployment units, those separate deployment units all need access to the same
data. Furthermore, data can be highly coupled in the form of foreign key
constraints, triggers, views, and even stored procedures (yes, believe it or not,
they still exist in the real world). If your data is too tightly coupled together,
consider something like service-based architecture instead of microservices.
Despite what some articles and blogs say, microservices is perhaps the most
complex architecture style that exists today. Consequently, it is also very
expensive. Licensing fees for platforms, products, frameworks, and databases all
rise exponentially based on the large number of services in a typical
microservices ecosystem. Therefore, if you have tight cost and time constraints,
avoid this architecture style and select a hybrid such as service-based
architecture.
Interestingly enough, most microservices architectures do not lend themselves
well to high-performance or highly responsive systems. While this may sound
surprising, it’s because in reality, microservices do in fact tend to communicate
with each other to access data and perform additional business functions.
Because the communication between services is remote, three types of latency
occur: network latency, security latency, and data latency.
Network latency is the amount of time it takes packets of information to reach
the target service over the network. Depending on the type of remote access
protocol you are using and the physical distance between services, this can range
anywhere from 30 ms to 300 ms or more.
Security latency is the amount of time it takes to authenticate or authorize the
request to the remote endpoint. Depending on the level of security and access
control on the remote service endpoint, this latency can range anywhere from a
few milliseconds to 300 ms or more.
Data latency impacts the performance aspects of microservices the most. Data
latency is the amount of time it takes for other services to query data on your
behalf that you don’t own. For example, suppose the Wishlist service needs
to access the product descriptions, and communicates with the Product
Catalog service to request the data. The Product Catalog service, upon
receiving the request, must make an additional database call to retrieve the
product descriptions. This is something that doesn’t happen when data is shared
in monolithic databases, where a single database call using an inner or outer join
is the only thing required to access multiple types of data.
Architecture Characteristics
The chart illustrated in Figure 6-4 summarizes the overall capabilities
(architecture characteristics) of microservices architecture in terms of star
ratings. One star means the architecture characteristic is not well supported,
whereas five stars means it’s well suited for that particular architecture
characteristic.
Figure 6-4. Architecture characteristics star ratings for microservices architecture
Chapter 7. Space-Based
Architecture

Most web-based business applications follow the same general request flow: a
request from a web browser is received by a web server, then an application
server, then finally a database server. While this type of request flow works great
for a small number of users, bottlenecks start appearing as the user load
increases, first at the web server, then at the application server, and finally at the
database.
The usual response to bottlenecks based on an increase in user load is to scale
out the web servers. This is relatively easy and inexpensive, and sometimes
works to address some bottleneck issues. However, in most cases of high user
load, scaling out the web servers just moves the bottleneck down to the
application servers. Scaling application servers can be more complex and
expensive than web servers, and usually just moves the bottleneck down to the
database, which is even more difficult and expensive to scale. Even if you can
scale the database, what you eventually end up with is a triangle-shaped
topology shown in Figure 7-1, with the widest part of the triangle being the web
servers (easiest to scale) and the smallest part being the database (hardest to
scale).
 Figure 7-1. The database is usually the ultimate bottleneck for highly scalable systems

In any high-volume application with an extremely large concurrent user load, the
database will usually be the final limiting factor in how many transactions you
can process concurrently. While various caching technologies and database
scaling and sharding products help to address these issues, the fact remains that
scaling out an application for extreme loads is a very difficult proposition when
it comes to the database.
The space-based architecture style is specifically designed to address and solve
these sorts of high scalability and concurrency issues. It is also a useful
architecture style for applications that have variable and unpredictable
concurrent user volumes (known as elastic systems). Solving extreme and
variable scalability needs is exactly what space-based architecture is all about.

Topology and Components

The space-based architecture style addresses the limitations of application
scaling by removing the database from the transactional processing of the system
—hence the name space-based architecture. This style gets its name from the
computer science term tuple space, the concept of multiple parallel processors
with shared memory. High scalability is achieved by removing the database
constraint and replacing the database with replicated in-memory data grids
during transactional processing. Application data is kept in memory and
replicated among all the active processing units, and synchronized with a
background database asynchronously using data pumps (more on that in the
following section).
Processing units can be dynamically started up and shut down as user load
increases and decreases, thereby addressing variable scalability. Because there is
no database involved in the transactional processing of the system, the database
bottleneck is therefore removed, providing near-infinite scalability within the
application. Figure 7-2 illustrates the topology of the space-based architecture
style.
 Figure 7-2. The space-based architecture style

Services in this architecture style are formally referred to as processing units. A

processing unit (illustrated in Figure 7-3) contains the business functionality and
varies in granularity from a single-purpose function to the entire application
functionality. Each processing unit includes business logic, an in-memory data
grid containing transactional data, and optionally, web-based components.
Processing units may also communicate with each other directly or through the
processing grid of the virtualized middleware (described in the following
section).

Figure 7-3. The processing unit contains the application functionality and an in-memory data grid
The complexity associated with this architecture style is managed through what
is called virtualized middleware. This middleware manages such things as
request and session management, data synchronization, communication and
orchestration between processing units, and the dynamic tearing down and
starting up of processing units to manage elasticity and user load. The four main
architecture components contained in the virtualized middleware are the
messaging grid, the data grid, the processing grid, and the deployment manager.
The messaging grid manages input request and session information. When a
request comes into the virtualized middleware component, the messaging grid
component determines which active processing units are available to receive the
request and forwards the request to one of them. The complexity of the
messaging grid can range from a simple round-robin algorithm to a more
complex next-available algorithm that keeps track of which request is being
processed by which processing unit. Typically, the messaging grid is
implemented through a traditional web server.
The data grid component is perhaps the most important and crucial component
in this style. The data grid interacts with the data-replication engine in each
processing unit to manage the data replication between processing units when
data updates occur. Since the messaging grid can forward a request to any of the
processing units available, it is essential that each processing unit contains
exactly the same data in its in-memory data grid as other processing units. The
data grid is typically implemented through caching products such as Hazelcast,
Apache Ignite, and Oracle Coherence, which manage the synchronization and
replication of the data grids. This synchronization typically occurs
asynchronously behind the scenes as updates occur in the in-memory data grids.
An additional element of the data grid is a data pump that asynchronously sends
the updates to a database. A data pump can be implemented in a number of
ways, but is typically managed through persistent queues using messaging or
streaming. Components called data writers asynchronously listen for these
updates, and in turn, update the database. Data writers can be implemented in a
number of ways, varying in granularity from application-level custom data
writers or data hubs to dedicated data writers for each processing unit type.
In the event of a cold start due to a system crash or a deployment, data readers
are used, leveraging a reverse data pump to retrieve data from the database and
pump the data to a processing unit. However, once at least one processing unit
having the same in-memory data grid is populated, additional processing units
can be started and populated without having to retrieve the data from the
database. Figure 7-4 illustrates the data grid containing the in-memory data
grids, data pumps, data writers, and data readers.
The processing grid component of the virtualized middleware is an optional
component that manages distributed processing for requests that require
coordination or orchestration between processing unit types. Orchestration
between multiple processing units can be coordinated through the processing
grid, or directly between processing units in a choreographed fashion.
 Figure 7-4. The data grid contains the in-memory data grid, data pumps, and data writers

Finally, the deployment manager component manages the dynamic startup and
shutdown of processing units based on load conditions. This component
continually monitors response times and user loads, starts up new processing
units when the load increases, and shuts down processing units when the load
decreases. It is a critical component to achieving variable scalability needs
within an application, and is usually implemented through container
orchestration products such as Kubernetes.

Examples
Space-based architecture is a very complicated and specialized architecture style,
and is primarily used for high-volume, highly elastic systems that require very
fast performance.
One example of the use of space-based architecture is a concert ticketing system.
Imagine what happens when your favorite rock band announces an opening
show and tickets go on sale. Concurrency goes from a few dozen people to tens
of thousands of people within a matter of seconds, with everyone wanting those
same great seats you want. Continuously reading and writing to a database
simply isn’t feasible with this kind of elastic system at such a high scale and
performance.
Another example of the kind of elastic systems that benefit from space-based
architecture is online auction and bidding systems. In most cases, sellers have no
idea how many people will be bidding, and bidding always gets fast and furious
toward the end of the bidding process, significantly increasing the number of
concurrent requests. Once the bidding ends, requests go back down to a
minimum, and the whole process repeats again as bidding nears the end—
another good example of an elastic system.
High-volume social media sites are another good example where space-based
architecture is a good fit. How do you process hundreds of thousands (or even
millions) of posts, likes, dislikes, and responses within a span of a few seconds?
Clearly the database gets in the way of this sort of volume (regardless of elastic
behavior), and removing the database from the transactional processing, as
space-based architecture does, and eventually persisting the data is one possible
solution to this complex problem.

Considerations and Analysis

Space-based architecture is a complex and expensive style to implement. As
such, it’s not suitable as a general-purpose architecture like the others reviewed
in this report. Rather, it’s meant for specific situations such as high scalability,
high elasticity, and high performance.
A unique feature of space-based architecture is its deployment model. The entire
architecture can be solely cloud based, solely on premises (on prem), or split
between the two. This latter deployment model is particularly effective for
cloud-based data synchronization where your main transactional processing is in
the cloud, but your data must remain on prem. In this model, the data writers and
data readers typically reside on prem alongside the database, and asynchronous
data pumps send data to the data writers from the cloud-based processing units.
Space-based architecture is considered a technically partitioned architecture
because domain functionality is spread across numerous technical artifacts,
including the processing units, in-memory data grids, data pumps, data writers,
and data readers. A domain-based change (particularly one involving a change to
data) usually impacts all of these artifacts.

When to Consider This Style

This architecture style is a great fit for those situations where you have very high
concurrent scalability or elasticity requirements. Processing tens of thousands of
concurrent requests (or more) becomes a big challenge when a database is
involved, and this architecture style removes the database from the scalability
equation, providing for near-infinite scalability.
Another use case to consider for this architecture style is those systems that
require very high performance and responsiveness. Because this architecture
style relies on in-memory caching, data update and retrieval are usually
measured in nanoseconds, which provides the most responsive and high
performance architecture out of all the architecture styles reviewed in this report.
When Not to Consider This Style
Even if you have high scalability and elasticity needs, this architecture may not
be something you should consider if you have large data volumes for your
transactional processing. Because all transactional data is stored in memory, the
overall size of your data becomes a limiting factor for space-based architecture.
Imagine trying to take a 45-terabyte relational database and trying to fit that in
memory!
Due to the technical complexity of this architecture style, it is not a good fit if
you have tight budget and time constraints. Furthermore, achieving very high
user loads in a test environment is both expensive and time consuming, making
it difficult to test the scalability aspects of the application. Because of this,
overall agility (the ability to respond quickly to change) is fairly low in this
architecture style.
Because space-based architecture is always eventually consistent, it may take a
lot of time before updates made in the in-memory data grids reach the database.
As such, space-based architecture should not be considered for those systems
that require high levels of data consistency between data sources.

Architecture Characteristics
The chart illustrated in Figure 7-5 summarizes the overall capabilities
(architecture characteristics) of space-based architecture in terms of star ratings.
One star means the architecture characteristic is not well supported, whereas five
stars means it’s well suited for that particular architecture characteristic.
Figure 7-5. Architecture characteristics star ratings for space-based architecture
Appendix A. Style Analysis
Summary

Figure A-1 summarizes the architecture characteristics scoring for each of the
architecture styles described in this report. One dot means that the architecture
characteristic is not well supported by the architecture style, whereas five dots
means it’s well supported by that style.
This summary will help you determine which style might be best for your
situation. For example, if your primary architectural concern is scalability, you
can look across this chart and see that the event-driven style, microservices style,
and space-based style are probably good architecture style choices. Similarly, if
you choose the layered architecture style for your application, you can refer to
the chart to see that deployment, performance, and scalability might be risk areas
in your architecture.
While this chart and report will help guide you in choosing the right style, there
is much more to consider when choosing an architecture style. You must analyze
all aspects of your environment, including infrastructure support, developer skill
set, project budget, project deadlines, and application size, to name a few.
Choosing the right architecture style is critical, because once an architecture is in
place, it is very hard (and expensive) to change.
Figure A-1. Architecture styles rating summary
About the Author
Mark Richards is an experienced, hands-on software architect involved in the
architecture, design, and implementation of microservices architectures, service-
oriented architectures, and distributed systems in a variety of technologies. He
has been in the software industry since 1983 and has significant experience and
expertise in application, integration, and enterprise architecture. Mark is the
founder of DeveloperToArchitect.com, a free website devoted to helping
developers in the journey to becoming a software architect.
In addition to hands-on consulting and training, Mark has authored numerous
technical books and videos, including the two latest books he coauthored,
Fundamentals of Software Architecture (O’Reilly) and Software Architecture:
The Hard Parts (O’Reilly). Mark has spoken at hundreds of conferences and
user groups around the world on a variety of enterprise-related technical topics.
When he is not working, Mark can usually be found hiking in the White
Mountains or along the Appalachian Trail.