MASARYK
UNIVERSITY
FACULTY OF INFORMATICS
Distributed Application
Architecture Patterns
Master's Thesis
BC. JURAJ FIALA
Brno, Autumn 2024
MASARYK
UNIVERSITY
FACULTY OF INFORMATICS
Distributed Application
Architecture Patterns
Master's Thesis
BC. JURAJ FIALA
Advisor: RNDr. Martin Kuba, Ph.D.
Department of Computer Systems and
Communications
Brno, Autumn 2024
MUNI
F I
Declaration
Hereby, I declare that this paper is m y original authorial work, w h i c h I
have worked out on m y own. A l l sources, references, and literature used or
excerpted during the elaboration of this work are properly cited and listed
in complete reference to the due source.
During the preparation of this thesis, I used the following AI tools:
• GitHub Copilot for predictive writing
• P h i n d and ChatGPT for research, brainstorming and review
• Grammarly for proofreading
• Semantic Scholar for literature review
I declare that I used these tools i n accordance with the principles of academic
integrity. I reviewed the content and take full responsibility for it.
Be. Juraj Fiala
Advisor: RNDr. Martin Kuba, Ph.D.
iii
Acknowledgements
I w o u l d like to thank m y advisor, doc. Ing. RNDr. Barbora Biihnová, Ph.D.,
for h e r remarkable insight and guidance, without w h i c h this thesis w o u l d
never have been possible, a n d RNDr. M a r t i n Kuba, Ph.D., for helping m e
take it over the finish line after her sudden passing. I would also like to thank
m y wife, Terézia, for h e r unwavering support a n d patience d u r i n g long
evenings and weekends, and m y family and friends for their neverending
encouragement.
iv
Abstract
Software patterns and their visualisations are powerful learning tools. However,
the existing literature on distributed application architecture patterns
is often fragmented a n d incomplete, presenting a n unnecessarily steep
learning curve. This thesis proposes a methodology for identifying these
patterns based on the current literature. It applies it to develop a structured
online catalogue o f the most prevalent patterns i n the field, their applications
and disadvantages, featuring accessible and consistent visualisations
and illustrative examples.
Keywords
software architecture, distributed systems, patterns, design patterns, architectural
patterns, microservices, cloud, containers, scalability, reliability,
resilience, performance, security, consistency, distributed transactions, m i gration,
compatibility
v
Contents
Introduction l
1 Methodology 2
1.1 Scope of this work 2
1.1.1 Distributed application patterns 2
1.1.2 Application architecture patterns 2
1.1.3 Design patterns 3
1.2 Existing resources 3
1.2.1 Classics 3
1.2.2 Service Oriented Architecture 4
1.2.3 Cloud computing 4
1.2.4 Microservices 4
1.2.5 Distributed systems 5
1.2.6 lA/ikipedia 5
1.3 Selection process 5
1.3.1 Categorisation 6
1.4 Pattern construction 7
2 Design and implementation 9
2.1 Inspiration 9
2.2 Visual style 10
2.2.1 Typography 10
2.2.2 Colour palette 11
2.3 Technologies 12
2.3.1 Diagrams 12
2.3.2 Website 12
2.4 Visual language 13
2.5 Design process 14
3 Overview 15
3.1 Prerequisites 15
3.1.1 Fallacies of distributed computing 16
3.1.2 CAP theorem 16
3.2 Pattern categories 17
3.3 Conventions used 18
3.3.1 Diagrams 18
3.3.2 Terminology 19
vi
3.4 Example application 19
4 Communication Patterns 20
4.1 Gateway Routing 21
Abstract service locations from the clients
4.1.7 API Gateway 23
4.2 Publisher-Subscriber (Pub-Sub, Topics] 24
Asynchronous one-to-many communication
4.2.7 Message Broker 26
4.3 Asynchronous Request-Reply 26
Asynchronous two-way communication
5 Decomposition Patterns 29
5.1 Sidecar 30
Language-agnostic, locally-running supporting components
5.2 Ambassador 32
Handle network communication on behalf of a service
5.3 Offload to Gateway 34
Move common functionality to a gateway to offload backend services
5.4 Backend for Frontend [BFF) 36
Reduce backend complexity by specialising for each frontend
6 Scalability Patterns 39
6.1 Competing Consumers & Load Balancer 40
Continuous parallel request processing
6.2 Partitioning (Sharding) 42
Scale out by separating tasks or data into logical partitions
6.2.7 Deployment Stamps 45
6.3 Scatter-Gather 45
Asynchronously distribute workloads and aggregate results
6.4 Externalised Configuration 47
Centralised configuration management
7 Resilience and Reliability Patterns 50
7.1 Bulkheads 51
Use logical partitions to isolate failures
7.2 Queue-Based Load Leveling 53
Use a messaging queue to manage and cope with peaks in demand
7.3 Retry 55
Do not fail because of transient errors
7.4 Health Monitoring 57
vii
Proactively check and react to service failures
7.5 Rate Limiting 60
Control the rate of incoming requests toprevent overload or starvation
7.6 Leader and Followers 62
Decentrally appoint a replaceable group leader
8 Performance and Latency Patterns 65
8.1 Circuit Breaker 66
Isolate failure with controlled recovery
8.2 Colocate 69
Improve network reliability by decreasing the distance between
services with high coupling
8.3 Aggregating Gateway 70
Aggregate multiple service requests into a single client response
8.4 Claim Check 72
Reduce message sizes by storing large payloads externally
8.5 Command and Query Responsibility Segregation (CQRS) . 74
Isolate data store reads and writes to prevent contention
9 Security Patterns 78
g.n. Identity provider & Federated Identity 78
Centralise authentication to reduce the attack surface
g.2 Gatekeeper (Service Firewall) 81
Protect services by validating and sanitising incoming requests in
a limited environment
10 Consistency Patterns 83
10.x Transaction-Based Processor 84
Use transactions to encapsulate atomic processes
a.0.2 Transactional Outbox 85
Atomically send a message and update the database
10.3 Saga 87
Sacrifice isolation for increased availability during a distributed
transaction
a.0.4 Choreography-Based Sagas 90
Distribute responsibility for a saga across participating services
a.0.5 Orchestration-Based Sagas 92
Centralise responsibility for a saga in a single service
a.0.6 Event Sourcing 93
Store data as a sequence of changes to preserve history
viii
ii Migration and Compatibility Patterns 96
11.1 Anti-Corruption Layer (ACL] 96
Mediate between modern and legacy systems
11.2 Incremental Replacement [Strangler Fig) 98
Replace a legacy system step-by-step
11.3 Messaging Bridge 101
Connect two services with incompatible messaging middleware
Conclusion 103
Bibliography 104
A Digital attachments 125
ix
Introduction
Over the past thirty years, patterns have become a n undisputable part o f
software development and architecture. They capture knowledge about common
problems and their solutions, help communicate, learn, and ultimately
avoid reinventing the wheel. It is all the more surprising that when it comes
to distributed systems, the literature becomes fragmented and incomplete,
with a steep learning curve.
This work aims to fill that gap by creating a complete, contemporary and
unopinionated catalogue o f distributed application architecture patterns
w i t h a n accompanying website, a i m e d p r i m a r i l y at m a k i n g the patterns
more accessible to newcomers to the field.
Chapter 1 examines the existing literature and defines a suitable scope
for the patterns based o n its deficiencies. It then proposes a methodology
for identifying, classifying a n d documenting the patterns. Chapter 2 describes
the process b e h i n d creating the diagrams and website and their
visual language.
Chapter 3 then provides the theoretical background and additional i n formation
needed to understand and navigate the patterns.
The 33 identified patterns are then presented i n the following chapters
by their corresponding categories: c o m m u n i c a t i o n (4), decomposition (5),
scalability (6), resilience a n d reliability (7), performance and latency (8),
security (9), consistency (10), and migration and compatibility (11).
The complete pattern catalogue is also available on the following website:
h t t p s : / / j u r f . g i t h u b . i o / d a a p / .
1
i Methodology
This chapter describes the methodology used for constructing the catalogue
in this work. Section 1.1 defines the scope of the work, § 1.2 reviews existing
literature, § 1.3 describes the pattern selection process and name resolution,
§ 1.3.1 details their categorisation and § 1.4 outlines the chosen structure of
the individual patterns.
1.1 Scope of this work
Defining the scope coincided with the literature review to prevent unnecessary
overlap with existing works. This work considers the following criteria
for choosing patterns.
1.1.1 Distributed application patterns
Patterns have to exclusively pertain to distributed systems. E a c h pattern has
to involve at least two discrete components. This w o r k does not strive to
rebrand existing m o n o l i t h i c system patterns unless they exhibit unique
characteristics when applied to distributed systems, such as Event Sourcing
(see § 10.6) or CQRS (see § 8.5), and not patterns such as Cache-Aside, which
is a technique universal to any system, or Index Table, w h i c h is a database
design pattern.
1.1.2 Application architecture patterns
Patterns have to pertain to application architecture, i.e. not algorithms (such as
specific leader election algorithms), data management principles, or specific
technologies (such as cloud services, databases or message brokers). They
should be future-proof and without a vendor bias.
Defining software architecture is h a r d [1, 2, p. 3, 3, p. 527] - this w o r k
settles on the heuristic that the patterns have to have a visualisable structure
to be considered architectural.
As such, this work does not a i m to cover messaging patterns i n general,
w h i c h were already covered b y H o h p e et al. [4] a n d stood the test o f time
well, data replication patterns, which were extensively covered by Joshi [5],
or the basics o f i n f o r m a t i o n security, such as asymmetric encryption or
certificates.
2
1. M E T H O D O L O G Y
1.1.3 Design patterns
The patterns have to be design patterns, i.e. not strategies, tactics, overall
architectural styles (such as SOA o r microservices), methodologies or antipatterns.
Architectural styles were already extensively covered by Richards
et al. [2] and Klimešová [6].
1.2 Existing resources
The scope defined i n § 1.1 creates an interesting gap that no existing source
seems to comprehensively cover.
This section provides what the author hopes to be a comprehensive
review o f existing literature o n distributed systems patterns. O n l y major
works containing constructed pattern sets or catalogues were considered to
ensure relevancy and consistency i n selection.
Methods employed include online searches, querying academic databases,
and reviewing the works' bibliographies. Unfortunately, m a n y nonacademic
works fail to provide a comprehensive list of references, so almost
every pattern required additional research to find the original source.
1.2.1 Classics
Martin Fowler's Patterns of Enterprise Application Architecture [7] is a natural
place to start, but it pertains mostly to layered m o n o l i t h i c systems (the
chapter o n distribution patterns only contains two patterns) and, importantly
- as Fowler notes [8] - completely omits asynchronous messaging.
This led to the creation o f Gregor H o h p e and Bobby W o o l f s Enterprise
Integration Patterns (2003) [4]. However, this, i n turn, only covers messaging
patterns and not the architecture as a whole.
The Pattern-Oriented Software Architecture (POSA) series defined a m u l titude
o f patterns d u r i n g its r u n . F r a n k B u s c h m a n n et al.'s Volume 2: Patternsfor
Concurrent and Networked Objects (2000) [9] and Volume 4: A Pattern
Language for Distributed Computing (2007) are most relevant to distributed
systems, with the latter being the last complete book on this topic. This work
considers all patterns later c o n f i r m e d b y Volume 5 (2007) [10], w h i c h was,
unfortunately, the last i n the series.
M i c h a e l Nygard's influential Release It! (2007) [11] focuses o n stability
patterns, a few of w h i c h are architectural. This work uses the updated 2018
second edition [12].
3
1. M E T H O D O L O G Y
1.2.2 Service Oriented Architecture
SOA, although now declined i n popularity [2, p. 242], was an important milestone
i n distributed computing, and it brought A r n o n Rotem-Gal-Oz's SOA
Patterns (2012) [13]. Despite the ageing technology references and vocabulary
it still holds up remarkably well, with quite a large overlap w i t h later works,
but often uses different names for the same patterns.
1.2.3 Cloud computing
Due to the rise of cloud computing i n recent years, several works have been
published documenting patterns used for architecting cloud applications.
The first was Bill Wilder's Cloud Architecture Patterns (2012) [14], documenting
a handful of patterns i n depth. Fehling et al.'s Cloud Computing Patterns (2014)
[15] was one of the inspirations for this work's structure and visual style and
has a whole chapter dedicated to cloud application architecture patterns. It
also has an accompanying website1
.
The major cloud providers have also published their o w n pattern catalogues.
T h e first was A l e x H o m e r et al.'s Cloud Design Patterns (2014) [16],
which later evolved into the open-source Azure Architecture Center series o n
Cloud Design Patterns [17]. It provides the most comprehensive list and often
tops the search results for the given pattern. However, it suffers from inconsistency
both i n the selection of patterns2
and i n structure, and is prone to
wrapping Azure products as patterns. A m a z o n Web Services also hosts Cloud
design patterns, architectures, and implementations, a catalogue b y A n i t h a
Deenadayalan [18], w h i c h covers fewer patterns but more consistently.
However, while m a n y cloud architecture patterns are applicable to any
k i n d o f distributed system, m a n y require a cloud environment to be fully
utilised.
1.2.4 Microservices
The advent of microservices brought Sam Newman's Building Microservices
(2015) [19] and the expanded 2021 second edition [3], w h i c h offer a comprehensive
guide but buries the patterns i n the text. Chris Richardson's
Microservices Patterns (2018) [20] fills this gap w i t h a complete catalogue but
lacks structure or overview diagrams. This is offset somewhat by the accompanying
website3
[21], but at the time of writing, it is still under construction,
and several patterns only have a skeletal structure.
1. https://www.cloudcomputingpatterns.org/
2. E.g. it i n c l u d e s the Index Table - a database pattern - i n the list
3. https://microservices.io/
4
1. M E T H O D O L O G Y
1.2.5 Distributed systems
In the last few years, several works have been published that focus on distributed
systems i n general. Brendan Burns' Designing Distributed Systems (2018)
[22] is closest to the scope of this work (with some focus also on containers),
but similarly to Richardson, opts for a deep dive instead of a catalogue. While
M a r k Richards and Neal Ford's Fundamentals of Software Architecture (2020)
[2] covers a few w e l l - k n o w n patterns, it takes a "new approach" and only
mentions t h e m i n passing. U n m e s h Joshi's Patterns of Distributed Systems
(2023) [5] is the most recent and most in-depth work, but focuses more o n
the technical aspects of constructing distributed systems and infrastructure,
with a focus o n data replication instead of the overall architecture.
There is also a work-in-progress sequel to EIP, Conversation Patterns,
by H o h p e [23], w i t h a last update i n 2017. Since it is not finished, is not
considered for selection of patterns, but it already includes useful patterns
that are referenced when appropriate.
1.2.6 Wikipedia
Wikipedia has a wide coverage of c o m m o n software patterns and, due to its
freedom of access, is often linked to, especially with older patterns, such as
the Gang of Four patterns [24], where it is quite comprehensive [25]. However,
w h e n it comes to distributed systems, this coverage is often sporadic and
lacklustre. This is a shame, as Wikipedia's encyclopedic nature and focus on
secondary sources would make it a valuable resource for this work. Still, due
to its open access and the educational nature of this work, it is referenced
as an additional source wherever applicable.
1.3 Selection process
This w o r k gathers patterns f r o m the sources defined i n § 1.2 a n d selects
those that meet the criteria defined i n § 1.1. A s patterns have to be "rooted i n
practice" [7, p. 10], it requires contemporary secondary sources to validate
the patterns' ongoing relevance a n d applicability, as it does not strive to
simply rephrase patterns.
Such a cutoff is inherently subjective, but necessary due to the change i n
landscape observable i n the literature. This w o r k settles o n defining "contemporary"
as anything that was released after containers and cloud - two
technologies that shaped the landscape the most - became prevalent.
5
1. M E T H O D O L O G Y
If a pattern is omitted i n a later edition of a book, this work also omits it.
Some authors define pattern boundaries differently. This w o r k tries to
handle these situations b y using the highest fidelity possible. O n the other
hand, i f different authors define different patterns that result i n the same
structure, this work discusses their differences under one name instead.
These kinds of conflicts require name resolution. This work balances the
following pillars.
• Familiarity. The name should match the original as close as possible.
The reason is twofold: to facilitate knowledge carryover and to enable
easy cross-referencing. If a different n a m e is chosen, the original
name is mentioned i n parentheses.
• Descriptiveness and intent. Each n a m e should p r i m e the reader
for the pattern's goals and means as comprehensively as possible.
It should not require additional context or knowledge to be understandable
[26, p. 26].
• Uniqueness. The pattern name should not clash with other existing
patterns used i n different contexts to prevent confusion.
Unfortunately, these pillars are often i n conflict and require a subjective
decision. This is documented alongside the pattern.
1.3.1 Categorisation
Most of the literature reviewed i n § 1.2 categorises patterns by what they are,
but this requires the reader to analyse the whole catalogue to find patterns to
solve a particular problem. Instead, this work categorises patterns by intent
so as to give the reader a clear motivation for each pattern a n d provide a
clear path for readers aiming to solve a specific problem.
Eight major categories were identified i n the patterns selected for this
work; these are detailed i n § 3.2. Each pattern is categorised by its p r i m a r y
intent, but it may belong to multiple categories secondarily. This is detailed
at the start o f each chapter. Thus, instead o f having to provide a guide o n
how to reach the desired solutions, this work aims to bake this information
directly into its structure.
Other categorisations were considered but created issues, such as the
following. Creating a messaging category would be useful to quickly identify
w h i c h patterns require messaging brokers, but this w o u l d m e a n that patterns
i n §§ 4.3, 6.1 and 10.5 would need to be split or would cause confusion,
as messaging is not necessarily part o f t h e m (even i f it often is). Creating
6
1. M E T H O D O L O G Y
a category for communicating with persistent data stores creates a similar
issue, such as with § 10.1. O n the other hand, traditional structural or behavioural
categories from [24] would mostly only overlap due to the implication
of the scope defined i n § 1.1.
Ultimately, they were discarded due to their incompatibility and limited
usefulness. In the end, patterns should never be applied unless they solve a
specific problem [24, p. 41], and this work aims to facilitate this.
1.4 Pattern construction
The following structure was chosen for the individual patterns. W h i l e it
is inspired b y the structures used i n the existing literature § 1.2, they are
inconsistent.
Due to the educational nature of this work, this structure is designed for
readers new to the topic. It is based o n the author's experience from trying
to understand these works and aims to solve the issues encountered, such
as missing summaries, motivation for the pattern being buried i n the text
or overlapping section concerns.
Name and summary The name of the pattern based on the process i n § 1.3
and as short as possible summary of the pattern to prime the reader
for the content.
Argumentation A summary of all sources and specific patterns this pattern
is based o n to show why this pattern is relevant, w h y it is included,
and how it relates to existing patterns.
Context What problems this pattern solves and what the prerequisites are
for its application.
Solution A n overview of how the pattern works, how to apply it and a visualisation
of the pattern based o n the design process i n § 2.5
Potential issues Since each pattern has its trade-offs, these are defined
directly after the solution to highlight the potential problems a n d
challenges that might arise f r o m applying the pattern.
Example A n example of the application to give the reader a more graspable
understanding of the pattern, based o n the system defined i n § 3.4.
7
1. M E T H O D O L O G Y
Related patterns What other patterns are related to this one, and why. This
section is used to explain differences between similar patterns and
to provide a path for further reading.
Further reading A n y additional sources that might be useful to better understand
the pattern.
8
2 Design and implementation
This chapter details the process and rationale behind the visual style (§ 2.2),
the diagram design process (§ 2.5), and the technological choices used to
construct it and the accompanying website (§ 2.3).
A c o m m o n downside of the literature detailed i n § 1.2 is the use of uninteresting,
sometimes downright bland visual styles. This is a shame, as these
patterns are inherently visual constructs, and a n engaging visual style can
have a significant impact o n the reader's understanding and engagement
[21].
2.1 Inspiration
One exception, however, is [15], which served as an inspiration for the visual
style o f this work. Out o f all o f the works reviewed, it is the only one w i t h
a visual style crafted to fit, w i t h consistent iconography a n d (albeit m o n o chrome)
colour scheme, even going as far as creating pictograms for each
pattern.
It has its downsides, however. While understandable for print, the monochrome
colour scheme shows its limits o n a screen, where the sacrifice to
readability feels particularly out-of-place, especially w h e n paired with the
muted blue used as a n accent o n the website, pushing the look to almost
dreary.
Another point is the choice of typeface. The diagrams employ Open Sans1
,
a well-made open-source font, but not k n o w n to be terribly exciting, which
is further diminished by the fact that, at the time of writing, it is the second
most popular typeface o n Google Fonts.
Curiously, it is paired w i t h Lato2
o n the website, also a well-regarded
open-source font, but these typefaces have such little contrast between
them that it almost seems something is off at first glance3
.
1. https://fonts.google.com/speci men/Open+Sans
2. https://www.latofonts.com/
3. Ironically, the better p a i r i n g u s e d i n the b o o k is w i t h Times New Roman
9
2. D E S I G N A N D I M P L E M E N T A T I O N
2.2 Visual style
This section discusses the choices made for the visual style of the diagrams
and website, n a m e l y the typography i n § 2.2.1 and the colour palette i n
§ 2.2.2.
2.2.1 Typography
One challenge to overcome is that m a n y conventional choices for sans
typefaces seem dull w h e n used i n a diagram, as they are usually optimised
for body text. For this reason, the diagrams i n this work use Space Grotesk4
,
a wonderfully funky open-source typeface that continually surprises w h e n
read. It becomes a bit overbearing w h e n used i n body text, but it works
remarkably well for short spurts of text, such as names i n diagrams.
Thus, the body text uses a m o r e grounded, serif typeface, Source Serif
Pro5
. It pairs well (see fig. 2.1), is readable (even o n screen), provides ample
contrast, and includes beautiful italics.
Space Grotesk Regular
Space Grotesk Bold
Source Serif Pro Regular
Source Serif Pro Italic
Iosevka Fixed SS09 Regular
Figure 2.1: Font selection
Lastly, for code snippets a n d U R L s , Space Mono and Source Code Pro two
monospace counterparts to the typefaces mentioned above - were considered
but proved too wide for use i n regular body text, especially for URLs.
4. https://floriankarsten.github.i o/space-grotesk/
5. https: //adobe-fonts. gi thub. i o/source- sen' f /
10
2. D E S I G N A N D I M P L E M E N T A T I O N
Instead, this work uses Iosevka6
, a generated and parametrisable typeface,
due to its very narrow structure. Specifically, it uses its 9th stylistic set, designed
to m i m i c Source Code Pro idiosyncrasies, w h i c h works well w i t h
Source Serif Pro.
2.2.2 Colour palette
The colour palette stems f r o m the practical needs o f the diagrams. It is
built u p o n a simple contrasting black and white base a n d adds two tones
for increasing and decreasing the level of focus - an orange-yellow hue for
highlights adds an inviting warmth to the diagrams, and a light, unobtrusive
grey for background objects finishes the visual hierarchy.
The palette also includes a light red for conveying failures or errors, and
finally, a dark, cold green adds a sense of comprehensiveness to the palette
and is useful as a secondary colour for foreground elements.
The palette roughly follows the popular 60-30-10 rule [28], providing a
balanced and airy feel (see fig. 2.2). It offers a dark mode with slight modifications,
such as decreased contrast for body text.
Figure 2 . 2 : Colour palette
A l l colour combinations used for text have at least a 7:1 contrast ratio,
achieving an enhanced W C A G rating (AAA) [29]. The palette performs well
for different types of colour blindness, except for blue-yellow colour blindness,
w h i c h is compensated for b y consistent shape-colour pairings a n d
supporting text (see § 2.4).
6. https://typeof.net/Iosevka/
11
2. D E S I G N A N D I M P L E M E N T A T I O N
2.3 Technologies
This section details the technologies used to create the diagrams (see § 2.3.1)
and the website (see § 2.3.2).
2.3.1 Diagrams
The diagrams are constructed using P l a n t U M L 7
, a text-based diagramming
tool that allows for easy version control and global styling. Joshi [5] already
proved its validity for this use case. It presents some challenges, as its lack of
granularity for controlling layout and limited style options are most visible
with big, prominent designs, such as those i n this work.
The biggest sore point is activity diagrams, w h i c h do not allow any control
over the layout o f the elements, so even simple diagrams can become
cluttered and hard to read. W h i l e P l a n t U M L does have tools to achieve the
layout needed, to access t h e m , one has to switch to a different diagram
type, w h i c h makes start and end nodes inaccessible. One workaround is to
design it as a state diagram w i t h a hide empty d e s c r i p t i o n statement, such
as fig. 10.3, w h i c h produces visually identical output, albeit requiring more
manual work.
Another c o m m o n issue is alignment. While P l a n t U M L generally places
elements o n a grid, it is relatively easy to be left w i t h angled, instead o f
perpendicular, lines, especially with nested elements. One possible solution
is to strategically apply norank to arrows, w h i c h relaxes some constraints
on the layout a n d m a y help straighten out the rest, such as i n the aforementioned
fig. 10.3. Switching to a l e f t t o r i g h t di r e c t i on c a n help w i t h
making horizontal forks balanced, such as i n fig. 6.4.
However, eventually, the last option is to give i n and change the design
to fit the tool or accept the limitations, such as with fig. 8.5. Some examples
are the inability to style certain elements, such as some types o f padding,
arrowheads, or line thickness being inconsistently applied. Other examples
are documented i n § 2.4.
Other tools exist, such as M e r m a i d 8
, but none seem to provide the same
level of features and control as P l a n t U M L .
2.3.2 Website
To account for dual-generation of this work - one into a PDF and one into a
website - the text is written i n Markdown with Y A M L front matter for custom
7. https://plantuml.com/
8. https://mermaid.js.org/
12
2. D E S I G N A N D I M P L E M E N T A T I O N
metadata, such as subtitles. The LaTeX M a r k d o w n package by Novotny [30]
is used to translate t h e m for LaTeX with custom Tenderers to read the front
matter and generate the subtitles accordingly.
Rendering H T M L is a bit more tricky. One option is to use Pandoc with
the chunkedhtml output [31, p. 147], but that only has support for documentlevel
metadata. To account for that, the front matter is extracted with Python
into a JSON file before processing with Pandoc, for later use with Eleventy9
,
a static site generator tool.
Styling is done w i t h T a i l w i n d C S S 1 0
and it is hosted o n G i t H u b Pages1 1
.
The website has support for mobile devices and dark mode.
2.4 Visual language
The visual language design is largely based on U M L but with some modifications
to make it more simple, intuitive and visually appealing.
Natural language is used instead of keywords, visual cues are preferred
over text, and multiple instances are explicitly s h o w n instead o f denoting
cardinality to make the diagrams as accessible and simple as possible.
Other aspects o f the visual language are dictated b y the limits o f Plant
U M L (see § 2.3), which, while having some control over the style and layout,
is fairly limited. This ultimately worked well for the overall direction of the
diagram design but did present some challenges.
The original design featured a jagged line used for errors, w h i c h w o u l d
improve the connotations of failure and also the recognisability with blueyellow
colour blindness. However, such a style is unsupported by PlantUML.
Using diagonal corners or dashed lines did not produce the desired effect,
so the final design settled o n sharp edges to convey errors.
Another unfortunate limitation is the lack o f hexagons, w h i c h some
newer works use to denote i n d i v i d u a l services [20, 3] (in reference to the
hexagonal architecture b y C o c k b u r n [32]). This w o u l d allow for a very clear
visual distinction between services a n d other entities, a n d P l a n t U M L has
added support for hexagons i n later releases. However, they are not present
in all diagram types, such as sequence diagrams, and even i n other diagrams,
they look unsightly oblong, with no control over their appearance. Thus, the
diagrams have to resort to consistent n a m i n g to mitigate this.
9. https://www.llty.dev/
10. https://tailwindcss.com/
11. https://jurf.github.io/daap/
13
2. D E S I G N A N D I M P L E M E N T A T I O N
2.5 Design process
Creating ideograms for the patterns, such as those employed i n 2.1 was
considered, but the issue is that b y nature, they can only convey a limited
amount of information to those unfamiliar with the underlying idea. However,
having a simple, understandable representation of the pattern could
be a very useful learning tool.
Therefore, this work instead uses a process to create pictograms called
eidetic reduction [33, pp. 39-42]. Eidetic reduction is a process defined by
Husserl i n 1913 [34], w h i c h involves iteratively simplifying a concept, keeping
only the elements essential to its representation, i.e. which constitute its
essence. This is a time-consuming process that requires a lot of experimentation
but results i n m u c h simpler diagrams than those used i n the literature
reviewed i n § 1.2 with only a limited sacrifice to informativeness.
14
3 Overview
This chapter presents an overview of the patterns and any additional information
needed to fully understand t h e m and the problems they solve. This is
discussed i n § 3.1. Section 3.2 presents an overview of the pattern categories,
§ 3.3 describes the conventions used i n this work, and finally § 3.4 introduces
the example application used to showcase the patterns.
3.1 Prerequisites
ACID transactions A c o m m o n acronym for the four properties of database
transactions: Atomicity, Consistency, Isolation, and Durability [35, 36].
BASE A n alternative acronym to ACID for eventually consistent systems: Basically
Available, Soft state, and Eventual consistency [37, 2, p. 132].
CAP theorem See § 3.1.2.
CRUD A c o m m o n acronym for the four basic operations of persistent storage:
Create, Read, Update, and Delete [38].
Event-driven architecture A n umbrella term for systems where components
communicate by emitting and reacting to events. Fowler separates
it into Event Notification, Event-Carried State Transfer, Event
Sourcing (see §10.6), a n d CQRS (see §8.5) to improve reasoning
about it [39]
Fallacies of distributed computing See § 3.1.1.
Idempotency A property of operations that can be applied multiple times
without changing the result beyond the initial application [15, p. 197,
4, p. 469].
Message broker, message-oriented middleware See § 4.2.7.
Poison message A message that failed to be delivered enough times [40]. It
can be moved to a dead-letter queue to wait for further inspection
[4, p. 123].
Strict/eventual consistency The two possible consistency models i n distributed
systems: strict is a CP system, and eventual is an A P system
(see § 3.1.2) [15, p. 127].
15
3. O V E R V I E W
3.1.1 Fallacies of distributed computing
Writing distributed systems presents several challenges that are not present
i n standard m o n o l i t h i c applications. These challenges are often underestimated,
w h i c h led to the formulation of the following^aZZacies of distributed
computing, first coined by Deutsch and other colleagues from Sun Microsystems
i n 1994 [2, p. 124, 41].
1. The network is reliable
2. Latency is zero
3. Bandwidth is infinite
4. The network is secure
5. Topology doesn't change
6. There is one administrator
7. Transport cost is zero
8. The network is homogeneous
Richards et al. [2, p. 131] also present additional considerations w h e n
creating distributed systems.
• Distributed logging makes tracking d o w n problems more difficult
• Distributed transactions are not ACID
• Contract maintenance a n d versioning is m o r e difficult due to the
additional required coordination between teams and departments
3.1.2 CAP theorem
The CAP theorem was formulated by Brewer [42] i n 1999 and later proven by
Gilbert et al. [43] i n 2002. It states that i n a distributed system, it is impossible
to guarantee all three of the following properties simultaneously:
1. Consistency - each node gives the same answer
2. Availability - each request receives a response
3. Partition tolerance - the system continues to operate despite network
failures
16
3. O V E R V I E W
Thus, w h e n building a distributed system, one can only choose two o f
these properties. A P systems (sacrificing consistency, i.e. eventually consistent
systems) are easier to build and scale, and CP systems (sacrificing availability)
are m u c h harder. Fortunately, these trade-offs do not need to be made o n a
system level; they can be m u c h more nuanced, such as o n a component or
operation level. [3, pp. 410-412]
3.2 Pattern categories
This work is structured around the following categories of patterns, starting
with two building block categories:
1. Communication patterns (chapter 4) shows options for communicating
between components and the outer world
2. Decomposition patterns (chapter 5) shows c o m m o n options on how to
deal with shared functionality
These patterns are then used to achieve the following quality attributes:
3. Scalability patterns (chapter 6) shows h o w to scale and manage scalable
systems
4. Resilience and reliability patterns (chapter 7) addresses the need for
handling inevitable network, software or hardware failures
5. Performance and latency patterns (chapter 8) shows how to solve comm
o n performance or latency issues arrising i n scaled or distributed
systems
6. Security patterns (chapter 9) shows security practices that c a n be
supported by the architecture of the system
7. Consistency patterns (chapter 10) details how to manage transactions
w h e n communicating between services
Finally:
8. Migration and compatibility patterns (chapter 11) shows patterns useful
for managing legacy or external systems
Patterns were distributed b y their p r i m a r y intent but m a y belong to
multiple categories secondarily. This is detailed at the start of each chapter.
17
3. O V E R V I E W
3.3 Conventions used
This work uses the following typographical conventions.
• Bold Title Case is used to identify (the first use of) a pattern name,
even beyond the scope of this work
• normal bold is used to highlight important keywords, namely i n
contexts or potential issues of a pattern
• Italic text is used to introduce new terms or concepts
• Monospace is used for code snippets or URLs
It also uses a consistent visual language, defined i n § 2.4, and terminology,
defined i n § 3.3.2.
3.3.1 Diagrams
The diagrams use a U M L - i n s p i r e d [44] visual language, s h o w n i n fig. 3.1,
with the following interpretations:
• A r r o w directionality implies only focus; c o m m u n i c a t i o n c a n still
flow i n the opposite direction
• Virtual diagram components are either logical or optional, depending
on the context
• A node is whatever computational unit is relevant, such as a server
or a virtual machine
• A n error i n the place of a service implies afailed service. This is always
also denoted i n the text, such as i n 7.1.
Figure 3.1: Visual language
18
3. O V E R V I E W
3.3.2 Terminology
Client/Service A relationship between an abstract "user" of a service that
does not necessarily have to be part o f the same system a n d an
autonomously r u n n i n g software component that c a n be accessed
over a network.
Producer/Consumer A relationship between two services w i t h a focus o n
the direction of data or message flow.
Request/Query A message from a client to a service that expects a response.
Mode A single computational unit such as a server or a virtual machine.
Task A single computational operation that can be performed by a service.
Processor A component with a focus on processing data or messages.
3.4 Example application
This work uses a fictional e-commerce platform, ExampleEshop, to illustrate
the patterns i n a real-world context. T h e platform's n a m e is purposefully
generic, not to require any additional context to understand its purpose.
It also does not use any specific technology stack o r architectural style;
additional details are always provided along with the pattern example.
For a better m e n t a l picture, ExampleEshop has roughly the following
properties. Some are arbitrary but were chosen for consistency, but also to
provide a simple enough domain so as not to require additional explanation.
1. It is large enough that it needs a distributed application to handle
the required load
2. It employs multiple development teams
3. It does not allow third-party sellers, only selling its o w n products,
but it has a broad selection of items
4. It operates o n a multi-national, but not necessarily a global scale
19
4 Communication Patterns
This chapter presents the fundamental building blocks regarding c o m m u nication
i n distributed systems.
1. The Gateway Routing pattern i n § 4.1 abstracts the location of the
underlying services f r o m any clients, presenting the system as i f it
was a single service
2. T h e Publisher-Subscriber pattern introduces a c o m m o n w a y to
decouple and scale c o m m u n i c a t i o n between services i n § 4.2 a n d
message brokers, a c o m m o n way to implement this communication
style, i n § 4.2.7
3. The Asynchronous Request-Reply pattern then fills i n a gap introduced
by employing messaging or asynchronicity i n general, that is,
how to handle responses, i n § 4.3
As distributed systems necessitate communication, many other patterns
could be included i n this chapter but are presented elsewhere due to their
focus o n other aspects of the system, such as:
• Ambassador (see § 5.2) handles c o m m u n i c a t i o n o n behalf of a ser-
vice
• Queue-Based Load Leveling (see §7.2) focuses o n h o w messaging
can improve reliability
• Competing Consumers (see §6.1) and Scatter-Gather (see §6.3)
extend messaging to bring scalability
• Messaging Bridge (see § 11.3) shows h o w to connect two systems
using incompatible messaging
• Transactional Processor (see § 10.1), Transactional Outbox (see
§ 10.2), and Event Sourcing (see § 10.6) show h o w to communicate
transactionally
• Choreography (see § 10.4) and Orchestration (see § 10.5) show how
to coordinate processes i n services
• Colocate (see §8.2) uses physics to speed u p c o m m u n i c a t i o n and
make it more reliable
20
4 . C O M M U N I C A T I O N P A T T E R N S
• Patterns i n ch. 7 can be necessary to handle communication failures
Overall, this is just a subset o f the topic and was covered i n depth by
Hohpe et al. [4] or Richardson [20, p. 85].
4.1 Gateway Routing
Abstract service locations from the clients
This pattern is based o n Gateway Routing b y Microsoft [45], Virtual Endpoint
b y Rotem-Gal-Oz [13, p. 64], a n d the API routing patterns b y Deenadayalan
[46]. H o h p e et al. define this pattern m o r e generically w i t h the
Message Router and Content-Based Router i n the context of a Pipes and
Filters architecture [4, pp. 91, 211, 47, 48].
This pattern is sometimes considered a part of the API Gateway pattern.
For notes o n why this work breaks it down, see § 4.1.7.
W h e n creating a client-facing distributed system, one of the first apparent
problems is how a client will interact with it since there is no longer a single
endpoint. T h e easiest solution is to create a c o m m o n routing service - a
Gateway Router.
4.1.1 Context
Apply this pattern i f there is a need to decouple service configuration from
clients and at least one of the following conditions holds.
1. The client needs to communicate with multiple backend services,
and their configurations change frequently, or it is not feasible to
update the clients
2. There is one backend service, but it has multiple running instances
or multiple versions, perhaps for progressive rollout or A/B testing
3. Traffic should be redirected to other w o r k i n g instances i n case o f
failure or overload
4.1.2 Solution
Introduce a singular gateway component (see fig. 4.1). Clients interact with
the system only through this component, containing all the necessary rules
to route the requests. This c a n be based o n several criteria, such as the
21
4 . C O M M U N I C A T I O N P A T T E R N S
hostname, U R L , port o r header. The gateway then forwards the request to
the appropriate service. This way, the clients never need to know the actual
service locations.
Client
Sends all requests
to a single location
Figure 4.1: Gateway Routing
4.1.3 Potential issues
The biggest downside of this pattern is that it introduces a single point of
failure - see chapter 7 on c o m m o n techniques to reduce resiliency i n similar
situations. A n o t h e r important aspect is the increase i n latency due to an
added j u m p i n the requests and the introduction of a possible bottleneck to
the system.
F r o m a higher point o f view, introducing this pattern makes it a very
appealing point to add m o r e features. This c a n accentuate the problems
outlined above. [3, p. 162]
4.1.4 Example
ExampleEshop (see §3.4) uses different APIs (see §5.4.4) for its different
frontend. I n order to avoid having to update all its apps after changes i n
deployments, it uses a single entry point that routes the requests to the
correct backend based o n the path. Thanks to the amount o f control this
gives them, they can also use it to test new versions of the backend services,
run experiments or re-route traffic i n case of failures.
4.1.5 Related patterns
• From another point of view, this pattern can be seen as an application
of Partitioning (see §6.2)
22
4 . C O M M U N I C A T I O N P A T T E R N S
• Instead o f having a universal gateway, w h i c h might introduce a
risk of handling too m u c h , consider breaking it down into multiple
Backends for Frontends (see § 5.4) to better split the concerns
• Aggregating Gateway (see § 8.3) builds upon the router and consolidates
multiple services calls into one to increase client performance
• Use Offload to Gateway (see § 5.3) to offload c o m m o n tasks to the
gateway to simplify services
• Introduce load balancing into the gateway w i t h Competing Consumers
(see § 6.1)
4.1.6 Further reading
• This functionality is often implemented i n a Reverse Proxy. Nygard
[12, p. 179] discusses their capabilities i n the context of load-balancing.
4.1.7 API Gateway
Gateway routing is sometimes considered part o f an API Gateway pattern.
However, that pattern, by definition, is a set of multiple functionalities, and
that coupling c a n lead to it being sometimes considered almost a n antipattern
[3, p. 162]. However, these discrete functionalities do not need to
be i m p l e m e n t e d i n one system. They can even be necessary i n some use
cases, so this work adopts the naming scheme propagated by Microsoft [17],
which splits the API Gateway into three discrete patterns - Gateway Routing,
Aggregating Gateway (8.3) and Offload to Gateway (5.3) [45, 49, 50].
The following sources are still very useful for insight into the individual
functionalities of an API Gateway, although they focus more on them being
deployed as a whole.
• Richardson [20, p. 260, 51] has a mostly positive take, arguing that
they are an essential part of most systems and can be very useful
• Newman [3, p. 162], on the other hand, is m u c h more sceptical of its
use i n , especially third-party solutions, but he admits it can have a
use under the right conditions, i.e. w h e n the team is small enough,
and it does not handle aggregation and filtering
• The API management Gateway component on W i k i p e d i a [52]
23
4 . C O M M U N I C A T I O N P A T T E R N S
4.2 Publisher-Subscriber (Pub-Sub, Topics]
Asynchronous one-to-many communication
This pattern is based o n the Publish-Subscribe Channel b y H o h p e et al.
[4, p. 113, 53], Publisher-Subscriber by Buschmann et al. [54, p. 234] and
Microsoft [55] and Publish-subscribe by Deenadayalan [56].
The name for this pattern is sometimes interchangeably used for communication
through message brokers i n general; see § 4.2.7.
4.2.1 Context
There is a need for asynchronous communication between a publishing
service and one or more consuming services (subscribers). Other supporting
factors include
• The need for loosely coupled or fluctuating components i n the
system
• The need for message buffering or guaranteed delivery
4.2.2 Solution
Introduce a message broker as a n intermediary between publishers a n d
subscribers (see fig. 4.2). This broker manages "topics," w h i c h consist o f
one input queue for the publisher and multiple output queues, one for each
subscriber. T h e publisher sends messages to the input queue, w h i c h the
broker processes and propagates to all the output queues.
Publisher
Publishes
messages to
• Topic
1/ Forwards
messages to
Subscriber 2
Figure 4.2: Publisher-Subscriber
The broker does not need to manage only one queue; once set up, it
can handle multiple topics, and each subscriber can choose which topics to
subscribe to.
24
4 . C O M M U N I C A T I O N P A T T E R N S
Existing message brokers typically also provide guaranteed delivery
but the implementation details are challenging and vary [3, p. 135] and, as
such, are outside the scope of this work. Other patterns described here may
assume that the broker provides this feature.
4.2.3 Potential issues
Using a broker means introducing another component into the system,
leading to increased complexity and possibly increased latency. Also, due
to its nature, it can become a single point of failure a n d thus a possible
bottleneck.
Having multiple subscribers can lead to ordering issues if the order of
messages is important, and, as with any network communication, message
duplication is a possibility and needs to be handled.
Furthermore, implementing a custom message broker may not be feasible
due to limited development resources, w h i c h m a y m e a n trusting a
third-party service.
4.2.4 Example
ExampleEshop (see § 3.4) uses a read-only database (see § 8.5.4) to improve
their performance when serving product pages. However, they have found
that even this is not enough to handle the surge i n traffic during large events.
To address this, they decided to replicate their read-only database. To ensure
that the data is consistent across all replicas, they subscribe to the same
topic to receive updates.
4.2.5 Related patterns
This pattern directly facilitates Scatter-Gather, which deals with destructuring
workloads into smaller tasks and reassembling the results (see § 6.3). It
is also possible to use a single messaging queue for communication instead
of a topic, w h i c h still includes the benefits of message buffering.
1. Using it i n one-to-one communication results i n Queue-based Load
Levelling (see §7.2)
2. Using it for one-to-many c o m m u n i c a t i o n results i n load-balancing
Competing Consumers (see § 6.1)
4.2.6 Further reading
• The "Gang of Four" Observer pattern [24, p. 273] this pattern builds
upon with asynchronous messaging
25
4 . C O M M U N I C A T I O N P A T T E R N S
• Wikipedia [57]
• The Inbox and Outbox pattern can also be used for guaranteed delivery
[58]
4.2.7 Message Broker
The categorisation, n a m i n g , and cross-section of messaging patterns vary.
Most centre around messaging middleware and queues [4, p. 76, 20, p. 85,
15, p. 136,14, p. 27], whilst others assume that terms such as "pub/sub" and
"competing consumers" are c o m m o n knowledge and do not need explaining
[3, p. 445, 12, p. 117, 20, p. 92]. This w o r k errs instead o n caution and
fidelity, presenting the most c o m m o n communication patterns but focusing
p r i m a r i l y o n the context i n w h i c h they are applied: see §§ 4.2, 4.3, 6.1, 6.3,
and 7.2.
• N e w m a n on topics [3, p. 135] and the Event-Driven Communication
pattern [3, p. 108]
• Richardson's general Messaging pattern i n Microservice Patterns [20,
p. 87, 59]
• Message-Oriented Middlew/are by Fehling et al. [15, p. 67]
• Burns [22, p. 129] calls it publisher/subscriber infrastructure
4.3 Asynchronous Request-Reply
Asynchronous two-way communication
This pattern is based on Request-Reply by Hohpe et al. [4, p. 147, 60], Asynchronous
Request-Reply b y Microsoft [61], Asynchronous Request-Response
by Hohpe [62], Request-Response Communication by N e w m a n [3,
p. 104], and partly o n the Messaging pattern b y Richardson [20, p. 87, 59]
and the Decoupling Middleware pattern by Nygard [12, p. 117].
The patterns have varying implementations but share the same structure
and purpose. A n overview is given below.
See also Message Broker (see § 4.2.7).
26
4 . C O M M U N I C A T I O N P A T T E R N S
4.3.1 Context
Synchronous messaging has become a bottleneck, but using only Publisher-Subscriber
(see § 4.2) or Queue-Based Load Levelling (see §7.2) is
not an option, as either
1. The client expects a response
2. One o f the c o m m u n i c a t i n g parties cannot use a messaging broker
due to technical limitations (e.g. a web browser), o r w h e n longrunning
connections are not feasible
4.3.2 Solution
There are three potential ways to implement this pattern.
1. Use a message broker (see § 7.2) and configure two queues: one for
the request and one for the response. The sender sends a message to
the request queue and waits for a response on the response queue.
2. Use synchronous communication to send the request, t h e n use
polling to check for a response on a pre-determined endpoint. This
option is less efficient as there w i l l be m o r e c o m m u n i c a t i o n overall,
but it might be easier to implement w i t h existing infrastructure
or tools. T h e receiver c a n improve efficiency b y replying w i t h an
estimate on the request completion [61].
3. Use synchronous communication and a callback mechanism. The
sender sends a request and a callback address. The receiver processes
the request and sends the response to the callback address. [62]
Figure 4.3: Asynchronous Request-Reply
27
4 . C O M M U N I C A T I O N P A T T E R N S
4.3.3 Potential issues
Compared to synchronous c o m m u n i c a t i o n , this pattern brings increased
latency a n d complexity. If i m p l e m e n t e d using synchronous calls, Retry
logic (see § 7-3) might need to be employed to handle transient failures.
Using synchronous communication is faster, simpler and more efficient
if the requirements allow it.
Using this pattern to c o m m u n i c a t e w i t h multiple parties m a y result
i n requests being processed out of order. This can be mitigated using a
Correlation Identifier [4, p. 154, 63].
See also § 4.2.3.
4.3.4 Example
Creating an order i n ExampleEshop (see § 3.4) is a complex operation implemented
as a distributed transaction (see § 10.3.4), which can take longer than
the timeout of a synchronous call. However, they want to provide feedback to
the user as soon as possible. Still, these updates do not have to be long-term,
as analytics showed that users stop refreshing the page once they receive
confirmation that their payment is through and an estimated delivery time.
Thus, for a simple implementation, they opted to poll the server periodically
to check the order status i n the initial phases w h e n many changes
are happening. Once the order is confirmed, the frontend stops polling and
informs the user that they w i l l receive further updates via email.
4.3.5 Related patterns
• While not necessary, Queue-Based Load Leveling (see § 7.2) can be
used to improve handling peak demand
• Retry (see § 7.3) logic might be necessary if using synchronous com-
munication
4.3.6 Further reading
• Request-response on W i k i p e d i a [64]
28
5 Decomposition Patterns
This chapter discusses how to code duplication and cross-cutting concerns
in a distributed system. It presents patterns that can be used to implement
m a n y others i n chapters 6-11. It starts w i t h two single-node patterns by
Burns [22].
1. Sidecar i n § 5.1 is a pattern that allows to offload cross-cutting concerns
to a locally r u n n i n g component, such as a container or a process,
i n a p r o g r a m m i n g language-agnostic w a y - w h i c h has since
become a general term for any locally r u n n i n g supporting compon-
ent
2. Similarly, Ambassador i n § 5.2 is a pattern that allows to handle
network c o m m u n i c a t i o n o n behalf o f a service, thus allowing it to
be extended with any functionality needed
It then continues with two c o m m o n approaches to handle client-facing
cross-cutting concerns:
1. Offload to Gateway i n § 5.3 is a simple pattern that puts shared functionality
into a gateway, w h i c h works w e l l for smaller applications
but does not scale
2. Backend for Frontend [BFF) i n § 5.4 is a (more costly) solution that
overcomes this issue and has been shown to work well i n practice
In a sense, other patterns could also be considered a part of this category:
• Bulkheads (see § 7.1) define general principles on how to decompose,
structure or isolate a system
• Identity Provider (see §9.1) and Externalised Configuration (see
§ 6.4) both extract functionality into c o m m o n services
• Gatekeeper (see § 9.2) forces decomposition to isolate security incidents
and Aggregating Gateway (see § 8.3) to improve performance
of unreliable clients
• Anti-Corruption Layer (see § 11.1) extracts functionality to preserve
semantics between different systems
• Messaging Bridge (see § 11.3) is a shareable component used for
connecting two services with incompatible messaging middleware
29
5 . D E C O M P O S I T I O N P A T T E R N S
Notable omissions i n this category due to the methodology described i n
§ 1 include:
• The Adapter pattern by Burns [22, p. 31], a complement to sidecars
and ambassadors, a term that did not seem to catch on, i n contrast
to the other two. In a sense, it can be seen as a sidecar anti-corruption
layer and is presented i n this work as such i n § 11.1
• T h e Service Mesh pattern b y Richardson [20, p. 380], a concept
mostly used i n the context of microservices
5.1 Sidecar
Language-agnostic, locally-running supporting components
This pattern is based on Sidecar defined by Burns [65, later 22, p. 11]. It was
originally defined specifically for implementation with containers but has
since become a general term for any process or container running alongside
a m a i n service; see Richardson [20, p. 410, 66] and Microsoft [67].
5.1.1 Context
Multiple services are created w i t h different, incompatible technologies
and need to share some functionality. Alternatively, the services might
need to offload some functionality so that it does not affect t h e m , but it is
still advantageous to have it close by.
5.1.2 Solution
Implement a small, locally running Sidecar service that provides the necessary
functionality (see fig. 5.1). This service communicates w i t h the m a i n
service over the network and can be deployed with multiple other services.
Since the sidecar is r u n n i n g o n the same node, it has access to all o f the
same local resources as the m a i n service.
This relationship does not necessarily have to be one-to-one1
. Depending
on the need, multiple services c a n attach to one sidecar, a n d one service
can have multiple sidecars attached to it.
1. T h i s is w h e r e the m e t a p h o r falls apart slightly
30
5 . D E C O M P O S I T I O N P A T T E R N S
z 71
Shared Mode
/ \
Main Service
\ )
/
Sidecar
V
Client V
Figure 5.1: Sidecar
5.1.3 Potential issues
Compared to a shared library, a sidecar will still add unnecessary overhead
and latency, even though it is running nearby. Since it lives separately from
the m a i n service, it also adds additional complexity to the system. Furthermore,
if the sidecar fails, it can affect the m a i n service, and debugging
across service boundaries can be more challenging.
Depending o n the type of functionality the sidecar provides, it can also
lead to tight coupling between the service a n d the sidecar, potentially
leading to the sidecar becoming a development bottleneck.
Since a sidecar runs on the same node as the m a i n service, it can be difficult
to scale. If the sidecar needs to handle disproportionately more work
than the m a i n service, consider offloading the functionality to a separate
service instead.
5.1.4 Example
ExampleEshop (see § 3.4) needs to process product images, but it also allows
users to post images i n their product reviews. These functionalities are
handled b y different services using different technologies. These need to
be converted into different formats and sizes, such as thumbnails or lowerresolution
images for mobile devices. To reduce code duplication, the image
processing is handled by a sidecar service deployed alongside both services.
This has the added benefit o f allowing m o r e fine-grained control over the
resource usage of the image processing and isolating any potential failures
from the m a i n services.
31
5 . D E C O M P O S I T I O N P A T T E R N S
5.1.5 Related patterns
This pattern expands u p o n the idea of the Colocate (see § 8.2) pattern. The
following patterns are commonly deployed as sidecars to improve perform-
ance.
1. Ambassador (see § 5.2), for placing helper services between clients
and m a i n services (see § <>)
2. Anti-Corruption Layer (see § 11.1), for abstracting different domains
Health Monitoring (see § 7.4) can be beneficial to implement as a sidecar
due to its close access.
5.2 Ambassador
Handle network communication on behalf of a service
This pattern is based o n Ambassador defined b y Burns [65, later 22, p. 21]
and Microsoft [68], and Client Proxy by Buschmann et al. [54, p. 240]. It can
also serve as a Channel Adapter by Hohpe et al. [4, p. 128, 69].
5.2.1 Context
This pattern handles the same problem described i n § 5.3.1 - there is a need to
offload commonly implemented functionality from services. Alternatively, a
legacy service cannot be altered but may still need some functionality added
to it.
5.2.2 Solution
Implement a small service that acts as a n intermediary between the m a i n
service and the network (see fig. 5.2). This service can be deployed alongside
the m a i n service and e n r i c h its networking capabilities without having to
modify the existing service. It can also be reused across multiple services.
5.2.3 Potential issues
Compared to a shared library, using an ambassador will result i n increased
latency due to the extra network hop, added system complexity, and an
additional point of failure. If a n ambassador is shared across multiple
services, it might become a bottleneck.
32
5 . D E C O M P O S I T I O N P A T T E R N S
71
Shared Node
r
Ambassador Service
Client
Figure 5.2: Ambassador
Consider the impact o f offloaded features o n the underlying service.
For example, automatically employing Retry logic (see § 7-3) might cause
problems i f the service endpoint is not idempotent.
5.2.4 Example
ExampleEshop (see § 3.4) wants to try out a new version of its recommendation
service w i t h a n updated m o d e l a n d evaluate its performance, but it is a
risky operation, so it needs to be rolled out gradually. This is a temporary
experiment, so they do not want to change the m a i n service. However, as
the recommendations are generated i n real-time as users browse the site, it
is critical for the experiment not to affect the latency of the application.
To achieve this, they deploy a n ambassador service that intercepts requests
to the recommendation service and forwards a percentage of t h e m
to the new version. Once the experiment is over, the ambassador service is
removed without needing to change the m a i n service. [22, p. 27]
5.2.5 Related patterns
• A n ambassador is c o m m o n l y deployed as a Sidecar (see §5.1) to
improve performance
• Patterns implementable i n a gateway include Rate Limiting (see § 7.5)
, Circuit Breaker (see § 8.1), Retry (see § 7.3), Partitioning (see § 6.2)
and Health Monitoring (see §7.4)
33
5 . D E C O M P O S I T I O N P A T T E R N S
• C o m p a r e d to Offload to Gateway (see § 5.3), this pattern has the
added benefit of being able to be configured per service and be deployed
as a sidecar for reduced latency. However, unlike it, it cannot
be easily extended with aggregation (see § 8.3)
• While an Anti-Corruption Layer (see § 11.1) lives i n the same space
as a n ambassador, they differ i n purpose. A n ambassador c a n be
reused across services; an A C L is, by definition, specific to a pair of
services and exists to isolate domain-specific logic
• The Gatekeeper (see § 9.2) pattern has a similar function but is deployed
i n a restricted environment for added security
5.3 Offload to Gateway
Move common functionality to a gateway to offload backend services
This pattern is based o n Gateway Offloading b y [50]. It is part of the three
patterns sometimes called a n API Gateway, as detailed i n § 4-1-7. O f the
three, this one is most prone to its pitfalls but can nevertheless be helpful i n
some scenarios.
The original n a m e seems to i m p l y that it is the gateway itself being
offloaded. Therefore, this work uses the t e r m Offload to Gateway instead,
which should better denote the direction of the offloading whilst preserving
recognisability.
5.3.1 Context
W h e n decomposing a system into multiple services, c o m m o n problems
m a y arise, such as caching, logging, m o n i t o r i n g , rate limiting, protocol
translation, authentication or authorisation. Repeating re-implementation
of these functionalities violates the basic Don't Repeat Yourself (DRY) [70,
p. 30] principle. It thus can be needlessly expensive and - perhaps more
importantly, when it comes to security - error-prone.
Whilst usable i n many scenarios, this pattern m a y be best utilised with
individual small teams due to the issues described below.
5.3.2 Solution
Introduce a gateway component that handles these cross-cutting concerns,
simplifying the underlying services (seefig.5.3).
34
5 . D E C O M P O S I T I O N P A T T E R N S
Shared
Functionality
Sends request
Client
Handles
Gateway
Forwards request
Service
Figure 5.3: Offload to Gateway
5.3.3 Potential issues
Similarly to Gateway Routing (see §4.1), this pattern can introduce a single
point of failure, a bottleneck and latency.
However, this pattern also has the potential to exacerbate these issues due
to the amount of functionality it can accumulate. These can lead to further
problems, such as introducing tighter coupling between the services and
the gateway and becoming a development bottleneck. [3, p. 162, 20, p. 267]
If using this pattern to implement authentication or authorisation, see
§ 9.1 o n potential security issues inherent to such a design.
5.3.4 Example
ExampleEshop (see § 3.4) already uses a gateway to route requests (see § 4.1.4)
to correct services and need to employ rate limiting (see § 7.5.4) to prevent
abuse. A s this needs to be applied to all user-facing services and this functionality
does not contain any business logic, they decided to go the simple
route and implement it i n the gateway itself.
5.3.5 Related patterns
• This pattern builds u p o n Gateway Routing (see § 4.1), as it must be
a single entry point
• Patterns implementable i n a gateway include Rate Limiting (see
§ 7.5), Competing Consumers (see § 6.1), Circuit Breaker (see § 8.1),
Retry (see § 7.3) and Health Monitoring (see § 7.4). However, see the
warnings i n the previous section
35
5 . D E C O M P O S I T I O N P A T T E R N S
• One possible mitigation of these issues is to separate the gateway into
multiple Backends for Frontends (see § 5.4), reducing its overall
scope a n d overlap. Another solution c a n be to use s m a l l services
deployed alongside applications to offload some concerns, such as
an Ambassador (see § 5.2), which can handle network-related shared
functionality, o r a Sidecar (see §5.1), w h i c h c a n handle isolated
concerns
• Simplify the client instead by using Aggregating Gateway (see § 8.3)
• A gateway can communicate with an Identity Provider (see § 9.1) to
authenticate clients
5.3.6 Further reading
• This pattern is often implemented with a Reverse Proxy. For several
examples, see Burns [22, p. 53] and [12, p. 179]
5.4 Backend for Frontend (BFF)
Reduce backend complexity by specialising for each frontend
This pattern is based on Back-end for Front-end [BFF) created by Calcado
[71], and later b y N e w m a n [72, 3, p. 480], Richardson [20, p. 265, 51] a n d
Microsoft [73]-
5.4.1 Context
There are several types of clients with the system, and they require serverside
aggregation. While the clients are typically individual frontends, this
pattern c a n apply i n other scenarios, such as providing a n A P I to a third
party [3, p. 487].
5.4.2 Solution
Implement a separate backend for each client. These backends process data
from shared services and handle all the necessary aggregation for the client.
This provides a natural separation o f concerns, helping mitigate the core
issue of Offload to Gateway.
36
5 . D E C O M P O S I T I O N P A T T E R N S
B a c k e n d
for F r o n t e n d A
B a c k e n d
for F r o n t e n d B
Frontend
D Frontend B
Figure 5.4: Backend for Frontend (BFF)
5.4.3 Potential issues
BFFs can introduce duplicated code. There are several potential ways to
deal with this problem.
1. Extract the code into a shared l i b r a r y thereby introducing coupling
between the BFFs
2. Merge the BFFs into a single service, thereby devolving back into
Offload to Gateway
3. Use the knowledge of where the duplication arises to introduce new
shared services
4. Tolerate the duplication as it may be worth the trade-off for the better
separation of concerns this pattern provides [3, p. 484]
Of course, as always, when introducing any new service, there is the risk
of introducing increased complexity a n d development overhead to the
system.
5.4.4 Example
ExampleEshop (see § 3.4) provides a web interface a n d two mobile applications
for different platforms. Each backend is a separate B F F c o n f o r m i n g
37
5 . D E C O M P O S I T I O N P A T T E R N S
to the different needs and functionality o f the frontends. The m o b i l e app
backends might provide a coarser-grained A P I to reduce the n u m b e r o f
requests, leverage that phone screens are smaller and can't display as m u c h
information as a desktop browser, or be structured differently due to the
differing designs and user experiences. [72]
5.4.5 Related patterns
• Even w i t h instances w i t h one client, using Aggregating Gateway
(see § 8.3) on itself can still be helpful to simplify logic on the frontend
and increase performance o n poor networks
• Use the Incremental Replacement [Strangier Fig) (see § 11.2) pattern
to migrate to BFFs
• Use a Identity Provides (see § 9.1) to authenticate requests
• Use an External Configuration Store (see § 6.4) to offset the complexity
of managing multiple BFFs
38
6 Scalability Patterns
This chapter details patterns that help to scale and manage scalable systems
- one of the fundamental driving forces behind distributed systems.
1. Competing Consumers & Load Balancer in § 6.1 have differing implementations,
but the same underlying structure and intent - to
distribute work among multiple identical consumers
2. Partitioning i n § 6.2, also k n o w n as sharding, is a similar pattern, but
with predetermined responsibilities for each participant, be it data
or tasks
3. Scatter-Gather i n § 6.3 presents a c o m m o n way to work with different
forms of partitioning
4. Externalised Configuration i n § 6.4 deals with management of scaled
systems
Other patterns that could be considered a part of this category include:
• Publisher-Subscriber (see § 4.2) can be used to scale broadcasts
• Choreography (see § 10.4) w h i c h helps scalability by losing dependence
o n a central coordinating, potentially bottlenecking, service
• Identity Provider (see § 9.1) improves handling of secrets i n scaled
systems
• Sidecar (see §5.1) for introducing shared functionality without a
bottleneck
• Ambassador (see §5.2) for plugging scaling services into existing
systems
• Colocate (see § 8.2) to apply physical restrictions to scaling to i m prove
scaling efficiency
• Rate Limiting (see § 7.5) to protect scaled systems f r o m individual
abusive clients
• Leader and Followers (see § 7.6) for coordination i n scaled systems
• Event Sourcing (see § 10.6) for easier replication i n scaled systems
Notable omissions i n this category due to the methodology described i n
§ 1 include:
• Pipes and Filters b y H o h p e et al. [4, p. 85] a n d Microsoft [74], due
to its classification as a n architectural style b y Richards et al. [2,
39
6. S C A L A B I L I T Y P A T T E R N S
p. 143]. Furthermore, describing it i n the context of distributed systems
does not add m u c h and presents notions already discussed i n
Choreography (see § 10.4)
• Map Reduce by Fehling et al. [15, p. 106] and Wilder [14, p. 59], as it
usually depends o n specific products, and has an identical structure
to scatter-gather
• Geode (Geographic Nodes) by Microsoft [75], which does not appear
outside of Azure and seems to just be a combination of load balancing
and eventual consistency wrapped around specific products
6.1 Competing Consumers Er Load Balancer
Continuous parallel request processing
This pattern is based o n two patterns w h i c h share the same structure and
purpose.
1. Competing Consumers b y H o h p e et al. [4, p. 446, 76], later b y M i crosoft
[77]. It is c o m m o n l y considered as part o f the functionality
of message brokers [20, p. 92, 3, p. 135]
2. Load Balancer b y H o h p e [78] and the Service Instance pattern
by Rotem-Gal-Oz [13, p. 62], w h i c h are c o m m o n l y implemented b y
reverse proxies [12, p. 178]
See also Message Broker (see § 4.2.7).
6.1.1 Context
The only condition to be able to utilise this pattern is to have independent
tasks a n d identical processors. There are a n u m b e r o f requirements that
can fuel this decision.
1. The need for increased throughput or decreased latency, even
under high load
2. The need for resiliency - if one consumer fails, the task can be picked
up by another
3. The task is composed of several subtasks w h i c h are highly dependent
o n each other
40
6. S C A L A B I L I T Y P A T T E R N S
6.1.2 Solution
Either use a Messaging Queue (see §7.2) to distribute tasks to multiple
identical consumers (seefig.6.1), which "compete" for the tasks (whichever
is faster takes the task), or use a [Gateway Router]#sec:gateway-routing) to
distribute the tasks with a load balancing mechanism.
Producer Queue
Send request 1
Send request 2
Send request 3
Consumer 1 Consumer 2
Deliver request 1
Deliver request 2
Deliver request 3
Figure 6.1: Competing Consumers
Since the processors are independent, their number can easily be scaled
up or down, depending o n the need.
6.1.3 Potential issues
Since the processors can have different speeds and latencies, messages might
be processed i n the incorrect order. There are two specific circumstances
where incorrect message ordering can be mitigated.
1. If processing the task does not have any side effects, attach a Correlation
Identifier [4, p. 154, 63] such as a timestamp or a sequence
n u m b e r and use Scatter-Gather (see § 6.3) to ensure the order o f
messages i n the output.
2. If the messages only need to be ordered w i t h i n a specific category,
use Partitioning (see § 6.2) and a single consumer per partition
41
6. S C A L A B I L I T Y P A T T E R N S
The limit of scaling is not infinite; the router may become a bottleneck
if the consumers are faster. O n the other hand, i f the consumers are not fast
enough, the router might be overwhelmed and may have to start dropping
messages.
If resiliency measures are implemented, the system might need to be
further guarded against poison messages or duplicated processing.
See also § 4.2.3.
6.1.4 Example
ExampleEshop (see § 3.4) uses a saga orchestrator (see § 10.3.4) to handle the
distributed transaction it needs to implement orders. However, the system
has trouble keeping up with the backlog of orders during large events, even
if using threading or asynchronous processing. Since they are already using
message queues (see § 7.2.4) to increase the reliability of the saga, they decide
to employ competing consumers to process the orders i n parallel.
6.1.5 Related patterns
• If the producers need a response, see Asynchronous Request-Reply
(§ 4.3)
• To improve performance, consider using a Claim Check to offload
the message queue i f the messages are heavy (see § 8.4).
To improve reliability and resilience, this pattern can be extended with
• Retry for handling transient failures (see § 7.3)
• Circuit Breaker to m a i n t a i n the system's responsiveness i n their
event (see § 8.1)
6.2 Partitioning (Sharding)
Scale out by separating tasks or data into logical partitions
This pattern is based o n two distinct but architecturally similar groups o f
patterns.
1. Partitioning data is typically discussed i n the context of databases as
sharding [3, p. 426] - Wilder's Database Sharding [14, p. 67], Burns'
Sharded Services [22, p. 59] and Sharding by Microsoft [79]
42
6. S C A L A B I L I T Y P A T T E R N S
2. Partitioning tasks goes b y different names, usually as a solution to
the ordering issue of Competing Consumers (see § 6.1) - Sequential
Convoy by Microsoft [80] or Richardson's sharded channels [20, p. 94]
6.2.1 Context
The data store or a specific task has become the bottleneck, or they surpass
the capacity o f a single machine. Still, it is possible to distribute t h e m
uniformly using some partitioning logic.
6.2.2 Solution
Instead of creating one shared data store or service, create multiple instances
and divide the data or tasks between t h e m (see fig. 6.2).
Partitioning Logic
— r
Uses!
Sends requests
Router
Instance 1
H
Partition 1
Partition 2 1
Client Instance 2 Partition 3
Figure 6.2: Partitioning (Sharding)
Since each partition is managed b y exactly one instance, the order o f
operations is guaranteed w i t h i n a partition, i n contrast to Competing Consumers
(see § 6.1).
If partitioning data, choose a fixed size of partitions to avoid repartitioning
the data i f the n u m b e r of data stores changes [5, p. 219].
6.2.3 Potential issues
Data partitioning logic design can be complex and is fundamental to the system's
performance. Choosing an incorrect scheme might require expensive
repartitioning. [3, p. 429]
Since one partition is managed by exactly one instance, additional resiliency
measures are needed to handle failures.
43
6. S C A L A B I L I T Y P A T T E R N S
6.2.4 Example
ExampleEshop (see § 3.4) receives a n influx of reviews during major events.
These reviews must be scanned for inappropriate content o r spam before
they are displayed and then compressed, w h i c h can take some time i f the
review contains images or videos. To handle the increased load, the system
uses Competing Consumers (see § 6.1). However, after introducing the ability
to update reviews, they noticed a rise i n failures.
This was due to users finding mistakes i n their text shortly after posting a
review containing a video. These edits only contained the edited text, which
was processed m u c h faster b y a different consumer and failed to save the
edit as the review did not exist yet.
ExampleEshop could fix this by disabling edits before they are screened,
but this could result i n users forgetting to edit their reviews later, decreasing
their overall quality a n d trustworthiness. A d d i t i o n a l logic could be introduced
to handle this, but this w o u l d have to be managed b y the queue.
Degrading to one consumer wasn't an option, as the influx of reviews could
easily overwhelm it. Instead, they decided to partition the review processors
by item. Each item was assigned r a n d o m l y to a single processor. This way,
the system's ability to scale was not altered significantly, but each review
event was guaranteed to be processed i n order.
6.2.5 Related patterns
• Even though the partitions do not increase the system's overall resiliency
per se, this can still be used to one's advantage to prevent
cascading failures. Introducing logical partitions for this purpose is
k n o w n as the Bulkhead pattern (see § 7.1)
• A n Ambassador can used to implement sharding logic on the client
side (see § 5.2) [22, p. 22]
6.2.6 Further reading
• N e w m a n o n data partitioning i n [3, p. 426]
• Joshi's Fixed Partitions pattern if the amount of participating data
stores can be variable [5, p. 219] and Key-Range partitions to optimise
for queries with ranges [5, p. 243]
• Shard (database architecture) o n W i k i p e d i a [81]. Also see [82] for a
similar concept i n storage systems
44
6. S C A L A B I L I T Y P A T T E R N S
6.2.7 Deployment Stamps
A n interesting sub-case of partitioning is partitioning users with Microsoft's
Deployment Stamps [83]. If the use cases of the system allow for creating
partitions o f users that do not have to share data, creating a distributed
system might not be necessary at all (see fig. 6.2.7).
Figure 6.3: Deployment Stamps
Partitions corresponding to geographic regions inherently facilitate low
latency (until the users travel).
6.3 Scatter-Gather
Asynchronously distribute workloads and aggregate results
This pattern is based o n Scatter-Gather b y Hohpe et al. [4, p. 267, 84] and
Deenadayalan [85], and Scatter/Gather by Burns [22, p. 73].
See also Message Broker (see § 4.2.7).
6.3.1 Context
At least one of the following conditions needs to hold.
1. M a n y external services need to be queried
2. The problem is embarassingly parallel1
1. "Embarrassingly parallel" is a t e r m used to describe problems that can be trivially divided
into smaller tasks that can be solved independently o f each other, w h i c h is the ideal scenario
for p a r a l l e l i s m [86].
45
6. S C A L A B I L I T Y P A T T E R N S
3. The operation needs to be r u n on a whole partitioned data store [22,
p. 73]
4. A n operation needs to happen with the lowest possible latency
6.3.2 Solution
This pattern has two possible implementations, depending on the use case.
1. The publisher sends out the same task using Publisher-Subscriber
(see § 4.2) to multiple different processors
2. The publisher independently sends out a different task to multiple
identical processors
Each processor then processes its task a n d sends its result back to a
central aggregator, w h i c h combines the results (seefig.6.4).
Figure 6.4: Scatter-Gather
Unless this operation is a part of an overall workflow, the aggregator does
not need to be a different entity than the publisher.
46
6. S C A L A B I L I T Y P A T T E R N S
6.3.3 Potential issues
Depending o n the use case, each processor might be a bottleneck, a n d
its failure might require retries that might delay the whole operation. Not
noticing a n error i n a processor might lead to incomplete results o r the
failure of the entire operation.
The parallelism o f a single operation m a y have a lower l i m i t than its
theoretical m a x i m u m due to network overhead (see § 3.1.1).
See also § 4.2.3.
6.3.4 Example
To improve search capacity, ExampleEshop (see § 3.4) partitions its search
index into multiple data stores. W h e n a user searches for a product, the
search service sends the query to all shards i n parallel using Publisher-Subscriber
(see § 4.2). The search service then aggregates the received results
and returns t h e m to the user.
6.3.5 Related patterns
• This pattern combines Publisher-Subscriber (see § 4.2) for sending
out tasks and Queue-Based Load Levelling (see § 7.2) for collecting
the results
• It is a natural fit for use with data using Partitioning (see § 6.2) when
implementing operations over the whole data store
• Use Queue-based Load Levelling (see §7.2) to decouple the processors
from the aggregator
6.4 Externalised Configuration
Centralised configuration management
This pattern is based o n Externalized configuration b y Richardson [20,
p. 361, 87], Managed Configuration b y Fehling et al. [15, p. 247, 88], and
External Configuration Store by Microsoft [89]
The Control Bus pattern by Hohpe et al. [4, p. 477, 90] is a similar concept,
using messages to control other services
47
6. S C A L A B I L I T Y P A T T E R N S
6.4.1 Context
W h e n creating many deployments i n a system, it might become challenging
to configure or update the configuration o f each instance properly. This
causes the system to become inflexible and increases the probability of user
error, w h i c h can lead to failures or security issues.
6.4.2 Solution
Centrally manage the configurations o f each service. The configuration is
either requested by the services themselves when they start or is requested
by the infrastructure when creating each service (see fig. 6.5).
Updates
Developer
Figure 6.5: Externalized Configuration
This is sometimes called pull-based externalised configuration or push-based
externalised configuration [20, p. 362-363].
6.4.3 Potential issues
The configuration might become a single point of failure. If the services
request the configuration themselves, changing the configuration store i m plementation
or location might require changes in all services.
If the number of services is very high, the services change frequently, or
the configuration needs to be updated online, the configuration store could
become a bottleneck.
6.4.4 Example
ExampleEshop (see § 3.4) employs partitioned data stores for its product catalogue
(see § 8.5.4) or its search index (see § 6.2.4). This requires managing
many instances, and any changes i n configuration, such as after upgrading
the database version, would require updating each instance manually. To address
this, the system uses a central configuration store. The infrastructure is
48
6. S C A L A B I L I T Y P A T T E R N S
configured to pull the configuration from this store on startup, allowing easy
updates and ensuring that all instances are running the same configuration.
6.4.5 Related patterns
The Identity Provider (see § 9.1) uses the same concept, but is used for
accommodating security rather than scalability.
6.4.6 Further reading
• The very similar Edge Workload Configuration pattern by Microsoft
[91], focusing more o n I0T2
use cases
2. Internet o f things
49
7 Resilience and Reliability Patterns
This chapter presents patterns that combat network unreliability and service
instability both of w h i c h are inevitable (see § 3.1.1) i n distributed systems.
As such, it is the largest chapter i n this work.
1. The Bulkheads pattern i n § 7.1 limits the impact of a failing service
on the rest of the system
2. The Queue-Based Load Levelling pattern i n § 7.2 evens out the load
between services
3. The Retry pattern i n § 7.3 guards against transient failures
4. The Health Monitoring pattern i n § 7.4 ensures the system is running
as expected
5. The Rate Limiting pattern i n § 7.5 protects services f r o m misuse
6. The Leader and Followers pattern i n § 7.6 coordinates services i n a
cluster without a natural leader
Other patterns that c o u l d be considered part o f this category include
[92]:
• Message brokers (see § 4.2.7) can improve communication reliability
• Circuit Breaker (see § 8.1) improves overall service reliability during
failures of its dependencies
• Ambassador (see § 5.2) and Offload to Gateway (see § 5.3) present
opportunities to implement these patterns
• Competing Consumers & Load Balancer (see § 6.1) provide natural
backups for failed services
• Claim Check (see § 8.4) can help recover message contents i n the
event of a disaster and Partitioning (see § 6.2) or Identity Provider
(see § 9.1) can limit the amount of information lost
• Chapter 10 discusses patterns to ensure consistency during failures
• Backend for Frontend [BFF] (see § 5.4) can be used to personalize
reliability for the different requirements of clients
• Gateway Aggregation (see § 8.3) c a n improve reliability w h e n a
client is slow or o n an unreliable network
• Strangler Fig (see § 11.2) improves reliability during transitional
periods
50
7. R E S I L I E N C E A N D R E L I A B I L I T Y P A T T E R N S
Notable omissions i n this category due to the methodology described i n
§ 1 include:
• Cache-Aside and Throttling by Microsoft [93, 94], although c o m m o n
techniques, do not add anything new to the discussion i n the context
of distributed systems and are not recognised as patterns b y other
authors
• Compensating Transaction by Microsoft [95] is discussed as part of
Sagas (see § 10.3)
7.1 Bulkheads
Use logical partitions to isolate failures
This pattern is based on Bulkheads by Nygard [12, p. 98], later by N e w m a n
[3, p. 400] and Microsoft [96].
"Bulkheads" are a concept borrowed f r o m shipbuilding, where, among
other things, they are used to divide the i n n e r space into rooms and to
prevent a breach i n one part of the ship f r o m leaking into the whole vessel
[97]. Translating this concept to software architecture means introducing
some k i n d o f logical partitions into the system to prevent failures f r o m
affecting other parts of the system.
In essence, this is the Partitioning pattern (see § 6.2) applied for a different
purpose - to increase resiliency instead of accommodating scalability.
7.1.1 Context
There are multiple interconnected parts o f a n application. A failure i n a
single part has the potential to cause failures i n others, and it is desirable to
keep some parts of the application r u n n i n g i n such an event.
7.1.2 Solution
Create logical partitions i n a system aimed at containing failures (see fig. 7.1).
There are several levels where bulkheads can be implemented.
In a n individual service, this can m e a n using different threads, processes
or pools1
for different tasks a n d independently manage their resource
limits and priorities to prevent starvation.
1. Pools i n this context m e a n any k i n d o f p o o l e d resource, e.g. w o r k e r pools [98]
51
7. R E S I L I E N C E A N D R E L I A B I L I T Y P A T T E R N S
PartialI y-Affected
Client
Fully-Affected
Client
Bulkhead 1
Working Service
Figure 7.1: Bulkheads
On the component level, this can be done by avoiding sharing resources
between services (or between clients), i.e. removing single points of failure.
This means if there is a failure i n one of the resources - or one of its clients
overloads it - it w i l l not affect all its clients.
On the deployment level, this can m e a n r u n n i n g each bulkhead o n different
nodes, isolating hardware failures, or using virtualisation.
At the highest level, this means designing a system w i t h bulkheads i n
m i n d , identifying mission-critical services and planning for potential
failures so that as m u c h of the system as possible continues operating independently
- or with limited functionality.
7.1.3 Potential issues
Employing bulkheads more leads to more resource usage and increased
complexity. It may also be difficult to introduce them into a tightly-coupled
system.
7.1.4 Example
ExampleEshop (see §3.4) has defined mission-critical functions that need
to be kept r u n n i n g at all costs, as outages w o u l d result i n significant financial
losses. These include basic product page functionality, basic search
52
7. R E S I L I E N C E A N D R E L I A B I L I T Y P A T T E R N S
and order processing. To achieve this, they are deployed separately from
other services and have their dedicated resources. They communicate with
dependencies using Ciruit Breakers (see § 8.1). If other features such as the
recommendation service, full text search or product reviews are unavailable,
they continue to function, either by using older, cached data or by providing
a degraded experience.
7.1.5 Related patterns
• Retry (see § 7.3) might prevent another bulkhead from failing if the
failure is only transient
• Circuit Breakers (see § 8.1) can be used to automatically "seal" a bulkhead,
speeding up fault handling and allowing the affected bulkhead
to recover
7.2 Queue-Based Load Leveling
Use a messaging queue to manage and cope with peaks in demand
This pattern is based on Queue-Based Load Leveling defined by Microsoft
[99], Queue-Centric Workflow; by Wilder [14, p. 27], Loose Coupling by
Fehling et al. [15, p. 156] a n d Decoupled Invocation by Rotem-Gal-Oz [13,
p. 47]. However, it is just a re-interpretation of the Point-to-Point Channel
pattern by H o h p e et al. [4, p. 111,100], focusing o n benefits they consider
part of messaging i n general [4, p. 16].
Nygard [12, p. 73] presents publish/subscribe messaging and message queues
as an alternative to improve the scalability of point-to-point communication
but does not elaborate o n their differences2
. Burns [22, p. 117] considers
handling bursts an inherent part o f the Work Queue pattern but instead
focuses on applying it for batch processing.
Richardson mostly inherits terminology from [4] and mentions message
buffering as a benefit of broker-based Messaging [20, p. 93]. So does Newman
[3, p. 107], but instead embraces the topic and queue terminology used by
brokers [3, p. 135].
This work uses the term Queue-Based Load Leveling as it best captures
the pattern's intent, as per guidelines defined i n § 1.3.
See also Message Broker (see § 4.2.7).
2. A n d later even calls it a pub/sub bus [12, p. 211]
53
7. R E S I L I E N C E A N D R E L I A B I L I T Y P A T T E R N S
7.2.1 Context
The system experiences variable load and does not manage to keep up when
demand peaks, leading to dropped requests.
7.2.2 Solution
Introduce a message queue into the service's communication channels (see
fig. 7.2). This queue can be used to buffer requests and allow the service to
process t h e m at its o w n pace.
Uneven
load
Queue
Balanced
load
Service
Client
Figure 7.2: Queue-Based Load Levelling
Since the service now does not need to be powerful enough to handle the
peak load, its computational resources can be scaled down, reducing the
cost of the system. Furthermore, the services now have decreased coupling
as they do not necessarily need to k n o w about each other.
7.2.3 Potential issues
See the potential issues i n § 4.2, n a m e l y increased latency, additional
complexity, and an additional point of failure, w h e n compared to direct
communication. Furthermore, using a queue means losing replies without
additional measures (see § 4.3).
See also § 4.2.3.
7.2.4 Example
The distributed transaction used for handling orders i n ExampleEshop (see
§ 3.4) handles business failures w i t h the Saga (see § 10.3) pattern, but this
does not handle technical failures. To address this, the system deploys a
message broker to handle the communication between services. This broker
persists messages until they are successfully processed and communicates
with the services transactionally (see § 10.1).
54
7. R E S I L I E N C E A N D R E L I A B I L I T Y P A T T E R N S
7.2.5 Related patterns
• Competing Consumers can be used at the other end of the queue to
increase throughput (see § 6.1)
• The queue can implement Rate Limiting to limit the rate of requests
to protect an underlying service (see § 7.5)
• Can be extended to two-way communication using the Request-Reply
pattern (see § 4.3)
7.2.6 Further Reading
• The Inbox and Outbox pattern can also be used for guaranteed delivery
[58]
7.3 Retry
Do notfail because of transient errors
This pattern is based o n Retry b y Microsoft [101], Retry with backoff b y
Deenadayalan [102], Request-Response with Retry b y H o h p e [103], AtLeast-Once
delivery by Fehling et al. [15, p. 144,104] and Request/Reaction
by Rotem-Gal-Oz [13, p. 114], and partly on the Busy Signal pattern by Wilder
[14, p. 83].
7.3.1 Context
A service connects to an external resource, and this request is either idempotent
or has some duplicate handling i n place. A failure would negatively
affect the currently r u n n i n g operation m o r e than any added latency. T h e
response either signalled the failure is transient explicitly (i.e. with a busy
signal [14, p. 83]) or there is a probability it is.
7.3.2 Solution
W h e n a failure occurs, retry the request. However, there are several options
on when to retry and for how long.
If latency is an issue, e.g. an interactive situation, and this type of failure
is k n o w n to be transient or to resolve quickly, retry immediately, w i t h a
fixed delay or with a linearly increasing delay, depending on the balance
needed.
55
7. R E S I L I E N C E A N D R E L I A B I L I T Y P A T T E R N S
If this is a long-running operation, an exponentially increasing delay
(also k n o w n as exponential backoff [105]) w o u l d be more suitable to avoid
collisions or overloading the service. [14, p. 88,101]
To prevent collisions, consider adding jitter to the delay [106].
The service might also estimate h o w long to wait, e.g. i f it employs a
Rate-Limitter (see § 7-5)Retry
until the failure is recognised as non-transient, or a timeout or a
m a x i m u m n u m b e r of retries is reached (see fig. 7.3).
c
Request to
external system h - 0
[success]
Timeout
retry]
-Kf)
[failure or timeout]
o [too many retries]
Error
Figure 7.3: Retry
7.3.3 Potential issues
If a service fails due to overload, retrying the request might exacerbate
the problem. If the retries are long-running, employing an inappropriatelydesigned
backoff algorithm might lead to collisions [106] (also k n o w n as the
thundering herd problem [107]).
Depending on the implementation, this pattern might introduce delays
or increased load (especially if the problem is mistakenly categorised as
transient). It m a y also result i n duplicate requests i f the network caused
the issues and the idempotency was not implemented correctly. If the calling
service has its o w n consumers, it might be better to let it react to the failure
instead [12, p. 93].
7.3.4 Example
ExampleEshop (see § 3.4) sends out transactional emails or newsletters to
its users. W h i l e this process is not idempotent, sending a n e m a i l twice is
not a critical issue - it is better than not sending it at all, especially i f it
contains important information such as an invoice or a password reset link.
56
7. R E S I L I E N C E A N D R E L I A B I L I T Y P A T T E R N S
To address this, the system uses a retry mechanism that resends the email if
it fails to be delivered due to network problems or a temporary issue i n the
recipient's email provider.
7.3.5 Related patterns
• Use a Circuit Breaker for avoiding retries i f a failure is long-lasting
(see § 8.1)
• Queue-Based Load Leveling typically implements retry logic (see
§7.2)
• Retries can be implemented i n a reusable Ambassador (see § 5.2)
7.3.6 Further Reading
• Nygard's thoughts o n retries [12, p. 93]
• N e w m a n o n timeouts [3, p. 397] and retries [3, p. 399]
• Exponential backoff on Wikipedia [105]
7.4 Health Monitoring
Proactively check and react to service failures
Health m o n i t o r i n g is a broad topic covered b y m a n y different but related
patterns. This pattern is based on the following: Health Endpoint Monitoring
by Microsoft [108], Watchdog by Fehling et al. [15, p. 260,109], Service
Watchdog by Rotem-Gal-Oz [13, p. 67], Health Check API by Richardson [20,
p. 366,110], and HeartBeat by Joshi [5, p. 93,111].
It is also part of the Control Bus and similar to the Test Message patterns
by Hohpe et al. [4, pp. 477, 498,112, 113].
7.4.1 Context
The system needs to adhere to availability or reliability requirements. Failures
i n the system need to be detected and either automatically resolved
or reported.
57
7. R E S I L I E N C E A N D R E L I A B I L I T Y P A T T E R N S
7.4.2 Solution
Proactively monitor the health of services (see fig. 7.4). The services either
implement a health check endpoint or send heartbeats to a central service.
The fidelity o f the health checks can vary f r o m simple up/down checks to
more complex checks that verify the service's resource usage, response
time, internal state or dependencies. This allows to cover a wider range of
potential issues than just whether the service is r u n n i n g or not.
In case of a failure or timeout, the system can automatically respond
by restarting the service, redirecting traffic to a healthy instance, or alerting
an operator.
7.4.3 Potential issues
Imperfectly designed or tuned health checks can lead to false positives,
false negatives or performance issues. A check that is too strict can cause
unnecessary service restarts, traffic redirection, or performance degradation
i f it is required too frequently or requires expensive tests.
On the other hand, checks that are too lenient or test too little can lead
to undetected issues, rendering the monitoring useless.
Figure 7.4: Health Monitoring
58
7. R E S I L I E N C E A N D R E L I A B I L I T Y P A T T E R N S
They can also introduce security risks by exposing sensitive information
or creating a vector for denial-of-service attacks. This can be mitigated by
endpoint authentication or obfuscation [108].
False negatives can also occur due to failures in the monitoring system
itself. Measures to mitigate this should be taken to ensure correct operation,
such as redundancy or self-checks.
7.4.4 Example
ExampleEshop (see § 3.4) uses health monitoring for all its r u n n i n g services.
If the service has an API, it exposes an authenticated /health endpoint,
which is polled regularly. This endpoint is configured to check the service's
dependencies, such as the database or the message broker. For databases, it
runs a test query. The system also monitors and logs the response times.
If the service fails, the m o n i t o r i n g system signals the infrastructure to
restart it and the load balancer (see § 6.1.4) to not route traffic to it. If it fails
repeatedly or is under a long-term h i g h load, the system sends an alert to
the operations team. For the parts critical to the operation (see § 7.1.4) of the
eshop, it also employs more sophisticated checks that are r u n less frequently,
such as for the search functionality, where it runs a pre-defined query and
checks i f the results are as expected, or for the order processing, where it
places a test order and checks i f it is successful.
7.4.5 Related patterns
• Health m o n i t o r i n g can be l i n k e d to a Circuit Breaker (see § 8.1) to
proactively respond to service state instead of relying on requests to
fail
• The Leader and Followers (see § 7.6) pattern can be used to autonomously
detect and recover from failures i f the system is dependent on
a single coordinating instance
7.4.6 Further reading
• Nygard [12, p. 162] on transparency
• N e w m a n [3, p. 305] on monitoring and observability
• Richardson on designing observable services [20, p. 364]
• Wilder on h o w to react to node failures i n [14, p. 93]
59
7. R E S I L I E N C E A N D R E L I A B I L I T Y P A T T E R N S
7.5 Rate Limiting
Control the rate of incoming requests to prevent overload or starvation
This pattern is based o n Rate Limiting by Microsoft [114]. Burns [22, p. 54]
mentions this as a denial-of-service defence.
It is sometimes considered as part of an API Gateway (see § 4.1.7) [20,
p. 262, 3, p. 163].
7.5.1 Context
This pattern can be implemented either server-side or client-side.
1. Server-side - several clients are using a single endpoint. Overuse
from one client can lead to decreased quality of service or even
starvation for others - a n d such a situation is not desired - or increased
costs for the provider. This can scale from accidental overuse
to misuse or even up to coordinated malicious efforts, such as
DD0S3
or Yo-yo4
attacks.
2. Client-side - a client wants to preemptively avoid errors while communicating
with an endpoint that is either rate-limited or has a limited
capacity and wants to reduce resource usage or improve communication
with users.
7.5.2 Solution
To protect an endpoint, i m p l e m e n t a stateful component that keeps track
of the n u m b e r of requests from each client over a specific time period (see
fig. 7.5). If a client exceeds their quota, it denies any future requests i n the
time w i n d o w and signals this appropriately back to the client. It can also
keep the client updated on their current usage so that they can adjust their
behaviour accordingly, but it may also withhold that information to prevent
coordinated attacks.
There are several approaches that can be used to implement rate limiting,
such as simple approaches like fixed or sliding window counters or classic
algorithms like token or leaky buckets [116]. The best approach w i l l depend
on the specific requirements (see [117, pp. 1504-1505] for a brief overview).
Requests over the limit can be either dropped or queued to be processed
later. There can also be several tiers of access. Unauthenticated users should
3. Distributed D e n i a l o f Service
4. A special type o f DDoS designed to over-provision c l o u d services [115]
60
7. R E S I L I E N C E A N D R E L I A B I L I T Y P A T T E R N S
Unlimited
stream
-W Rate Limiter
Limited
stream
Service
Client
Figure 7.5: Rate Limiting
be rate-limited more strictly, as they can be harder to identify and are easier
to scale with attacks [22, p. 54].
7.5.3 Potential issues
Adding a rate limiter increases complexity and m a y introduce overhead,
latency, or bursts, depending on the load and implementation. Optimising
for throughput m a y require specialised hardware. [117, p. 1505] Faulty
implementations may become a bottleneck or be bypassed by attackers.
Configuration needs to be carefully tuned to balance throughput and
fairness.
7.5.4 Example
Some of ExampleEshop's (see § 3.4) users (or perhaps competitors) employ
bots to scrape the site for price changes. This puts a significant load on the
system and degrades the performance for legitimate users. To prevent this,
the system uses rate limiting to restrict the n u m b e r of requests a single
IP address can make i n a given time frame. To reduce false positives, the
system tracks the n u m b e r of requests made b y logged-in users separately
from anonymous users.
7.5.5 Related patterns
As this pattern serves to protect and m a y need to be applied i n several
places, it might be desirable to use a c o m m o n implementation with Offload
to Gateway (see § 5.3) or an Ambassador (see § 5.2).
A client can use a Queue (see § 7.2) to store requests for processing, the
estimation i n the request replies to plan Retries (see § 7.3), or a Circuit
Breaker (see § 8.1) to fail-fast until the limit is lifted.
61
7. R E S I L I E N C E A N D R E L I A B I L I T Y P A T T E R N S
7.5.6 Further Reading
• Wikipedia [118]
• Wilder [14, p. 87] on reacting to Busy Signals
7.6 Leader and Followers
Decentrally appoint a replaceable group leader
This pattern is based on Leader and Followers by Joshi [5, p. 85,119], Leader
Election by Microsoft [120], and Ownership Election by Burns [22, p. 93].
7.6.1 Context
A group of peer service instances with no natural leader need to coordinate
their actions. However, the group needs to be resilient to the leader's failure,
and the leader is replaceable.
7.6.2 Solution
Each service has one of the following states: Leader, Follower, or Looking for
Leader (sometimes called Candidate). Each service starts a leader election
on startup and does not accept requests until a leader is elected.
Once a leader is elected, it sends HeartBeats [see 5, p. 93] to the followers.
If the followers do not receive a heartbeat within a specific time, they start a
new leader election (see fig. 7.6).
There are a n u m b e r of algorithms for leader election, such as Zab [121]
or Raft [122].
Alternatively, if there is an implicit order i n the group, such as the service
age, this can be used to determine the leader without an election, k n o w n as
the Emergent Leader pattern [5, p. 375].
7.6.3 Potential issues
The added complexity of leader election may not be necessary, depending
on the availability requirements of the system.
The leader may become a bottleneck i f responsible for too m u c h work.
If this cannot be mitigated otherwise, one option is to have the leader not
participate i n the work itself, only i n its coordination.
62
7. R E S I L I E N C E A N D R E L I A B I L I T Y P A T T E R N S
Instance 1
(Elected Leader)
Sends
heartbeats
Sends
heartbeats
Instance 2
[Follower]
Start election on timeout
Instance 3
[Follower]
Figure 7.6: Leader and Followers
A fault i n the algorithm implementation can lead to split-brain5
scenarios,
where multiple leaders are elected.
7.6.4 Example
ExampleEshop (see § 3.4) uses health m o n i t o r i n g to check the status o f its
services. The system uses multiple monitors to accommodate for possible
failures and handle the number of service instances they operate. However,
they need to coordinate o n h o w to handle failures so as not to result i n
conflicts, such as multiple restarts. Furthermore, there is no natural leader,
as all monitors are equal. To address this, the monitors use leader election
to select a single m o n i t o r to react to failures. If this m o n i t o r fails, other
monitors w i l l elect a new leader.
7.6.5 Related patterns
• Health Monitoring for more details on heartbeats (see § 7.4)
5. Rotem-Gal-Oz [13], [p. 66]
63
7. R E S I L I E N C E A N D R E L I A B I L I T Y P A T T E R N S
7.6.6 Further reading
• Joshi's HeartBeat pattern for leader failure detection [5, p. 93,111],
and the Emergent Leader pattern [5, p. 375] for avoiding the need
for an election protocol
• Nygard [12, p. 305] on using leader elections for achieving loose clus-
tering
• Wikipedia [123]
64
8 Performance and Latency Patterns
This chapter presents patterns that do not necessarily facilitate scalability
but solve some specific performance o r latency issues introduced b y the
distribution.
1. The Circuit Breaker pattern i n § 8.1 improves latency i n the event of
a failing service so that a service can respond appropriately without
having to wait for timeouts
2. The Colocate pattern i n § 8.2 names a simple fact: the closer two
services are, the faster and more reliably they can communicate, and
this needs to be considered w h e n designing a distributed system
3. The Aggregating Gateway pattern i n § 8.3 improves the performance
of clients o n unreliable or slow networks b y doing the heavy
lifting for them
4. The Claim Check pattern i n § 8.4 offloads communication by storing
large payloads i n a shared location so that they do not need to be
handled by message brokers or services that do not need them
5. Under specific circumstances, the Command and Query Responsibility
Segregation (CQRS) pattern i n § 8.5 can improve performance
by separating the read and write sides of a service
Other patterns that could be considered part o f this category include
[124]:
• Asynchronous Request-Reply (see §4.3) can improve concurrency
and scheduling o f the services b y allowing t h e m to respond to requests
at their o w n pace
• Backend for Frontend (see § 5.4) enables performance optimisation
for specific use cases
• Choreography (see § 10.4) can improve performance by removing
the bottleneck of a central coordinator
• Competing Consumers (see § 6.1) can improve throughput and load
distribution
• Event Sourcing (see § 10.6) can improve throughput by decreasing
contention w h e n writing and better performance of replication
• Identity Provider (see § 9.1) removes the need for individual services
to handle authentication
65
8. P E R F O R M A N C E A N D L A T E N C Y P A T T E R N S
• Health Monitoring (see § 7.4) can provide resource usage data to load
balancers to maximise performance
• Partitioning (see § 6.2) can decrease contention for resources and
reduce data set sizes
Notable omissions i n this category due to the methodology described i n
§ 1 include:
• Cache-Aside, Index Table, Materialised View by Microsoft [93,125,
126], as they are not specific to distributed systems
• Compute Resource Consolidation and Static Content Hosting by
Microsoft [127,128] and Valet Key by Wilder and Microsoft [14, p. 115,
129] as they are only useful i n cloud environments
• Content Distribution Network by Fehling et al. [15, p. 300] and the
CDN pattern by Wilder [14, p. 125], as they are tied to specific products
with global infrastructure
8.1 Circuit Breaker
Isolate failure with controlled recovery
This pattern is based o n Circuit Breaker by Nygard [12, p. 95] and further
elaborations by N e w m a n [3, p. 401], R i c h a r d s o n [20, p. 77,130], Microsoft
[131] and Deenadayalan [132].
A circuit breaker is an electronic safety device that protects circuits
from overcurrent [133]. This pattern stretches this metaphor slightly, but
this w o r k keeps this name as it gives a good intuition for its function and
might potentially help w i t h c o m m u n i c a t i o n w i t h people already familiar
with the concept, although the terminology implied by the metaphor can be
(unfortunately) misleading for software developers.
8.1.1 Context
A service is communicating with an external resource. In the event of failure,
it is more beneficial to fail immediately until it is resolved than to try to get
a response eventually.
66
8. P E R F O R M A N C E A N D L A T E N C Y P A T T E R N S
8.1.2 Solution
Introduce a stateful proxy with the following states (see fig. 8.1).
1. Closed - this is the default state. The proxy passes along requests
but keeps track of failures.
2. Open1
- enough failures have occurred to trip the breaker, "opening"
the circuit, immediately returning an error on any requests.
3. Half-open2
- a c o o l d o w n timer has r u n out, and the breaker starts
routing requests through again. However, on the first failure, it trips
back open and resets the timer.
Closed
do / Return result
Enough failures
A request failed
/ Increase failure count
Enough successes
/ Reset failure count
Open
after(timeout]
/ Reset success count
f \
Half-Open
do / Return failure A request failed do / Return result
^ J
2
Request succeeded
/ Increase success count
Figure 8.1: Circuit Breaker
M a n u a l operation of the breaker might also be desirable i n certain use
cases.
8.1.3 Potential issues
While the additional overhead circuit breakers introduce is m i n i m a l , they
can still impact h i g h throughput services a n d introduce additional complexity.
The breaker also needs to be tuned correctly a n d specifically to
each service, as, if it is not, it might trip just due to transient failures causing
1. C o m i n g f r o m software d e v e l o p m e n t , this t e r m i n o l o g y c a n be v e r y c o n f u s i n g . T h i s
w o r k c o n s i d e r e d u s i n g a different n a m i n g b e c a u s e a n " o p e n " p r o x y h a s t h e c o m p l e t e l y
opposite connotations that it should. However, this w o u l d , unfortunately, c o m p l e t e l y break
the m e t a p h o r a n d a d d c o n f u s i o n to discussions i n v o l v i n g people already f a m i l i a r w i t h this
n a m i n g scheme.
2. A g a i n , the n a m i n g c o n v e n t i o n is a bit m i s l e a d i n g . T h e breaker is practically closed but
w i l l trip o p e n m u c h m o r e easily.
67
8. P E R F O R M A N C E A N D L A T E N C Y P A T T E R N S
failures, r e m a i n i n an open state far longer than the underlying service is
down, prolonging downtime, or switch between open and half-open stats
too frequently, reducing reliability.
Circuit breakers should only be used for remote resources, as they may
add too m u c h overhead for local operations [131].
8.1.4 Example
ExampleEshop (see § 3.4) uses circuit breakers between its bulkheads (see
§ 7.1). If a bulkhead fails, the circuit breaker trips and isolates the failure.
This allows the rest of the system to fall back to a degraded mode, such as
using older, cached data or providing a degraded experience, without having
to wait for timeouts, w h i c h can be critical for business operations3
.
8.1.5 Related patterns
This pattern has an interesting resonance with Retry (see § 7.3). If retry logic
is placed after a circuit breaker, it m a y delay the failure too long, causing
many more requests to come through and fail before the breaker trips. Retry
logic can still be useful before the circuit breaker, e.g. to protect from transient
network failures, but an incorrect configuration combination can cause
the circuit breaker to trip too often.
As a rule of thumb, the circuit breaker is better i n interactive situations,
where failing fast might be more important than getting a response. Retrying,
on the other hand, is better for long-running operations, where the service
might recover i n time.
Instead of retrying, Competing Consumers can be used to re-route requests
to a healthy backup service (see § 6.1). Or, as a compromise, instead
of trying to push the request through the breaker, the breaker can actively
check the state of the underlying service akin to Health Monitoring (see
§ 7.4) and close itself once the service is healthy again. Staying with the same
pattern, the circuit breaker is also an important source of information which
can be used for alarms and analysis.
The external service might employ Rate Limiting (see § 7.5), w h i c h is
important to acknowledge w h e n designing the breaker.
If the system employs Bulkheads (see § 7.1), the circuit breaker can be
used to close off a failing bulkhead and proactively enter a restricted mode
of operation.
3. Dieulot c o m p i l e d a n interesting list o f sources o f h o w even s m a l l changes i n response
times lead to m e a s u r a b l e changes i n user b e h a v i o u r [134]
68
8. P E R F O R M A N C E A N D L A T E N C Y P A T T E R N S
If the implementation needs to be shared a m o n g multiple services of
incompatible technologies, the circuit breaker can be implemented as part
of an Ambassador (see § 5.2) or Offload to Gateway (see § 5-3)-
8.1.6 Further reading
• Wikipedia [135]
8.2 Colocate
Improve network reliability by decreasing the distance between services
with high coupling
This pattern was explicitly defined only by Wilder [14, p. 109], but is directly
leveraged by other authors i n other patterns (see §§ 8.3, 5.1, 5.2 and 11.1).
8.2.1 Context
Heavy traffic between two parties leads to additional network latency and
unreliability, w h i c h has a significant performance impact.
8.2.2 Solution
Decrease the network distance between parties w i t h h i g h coupling (see
fig. 8.2). This might include deploying services to the same node, m o v i n g
services to the same L A N or data centre, or moving services geographically
closer to their clients.
Data Centre 2
Slovu Service
High latency
1
Data Centre 1
Lovu latency
Fast Service
Figure 8.2: Colocate
8.2.3 Potential issues
Moving services together might make the system less resilient to failures, as
they might share the same physical resources (see § 7.1).
69
8. P E R F O R M A N C E A N D L A T E N C Y P A T T E R N S
8.2.4 Example
Searching i n ExampleEshop (see § 3.4) is a critical part of the system, as it is
the primary way users find products. The search index is partitioned across
multiple data stores (see § 6.2.4) to handle the load. However, this means
that the amount of network traffic needed to search the index is m u c h higher
than if the index was stored locally and that the speed of the slowest response
dictates the speed o f the search. Furthermore, w i t h m o r e partitions, the
chance of a network request failing increases. To combat this, they m o v e d
the partitioning logic into a separate component that they deployed close to
the data stores. This way, most o f the network requests are fast a n d more
reliable, w h i c h improves the overall search performance and reliability.
8.2.5 Related patterns
This idea of placing services close to each other is a c o m m o n theme i n
several other patterns.
1. A Sidecar builds u p o n this pattern to provide additional, languageagnostic
functionality to a service by deploying it alongside the m a i n
application (see § 5.1)
2. Similarly, an Ambassador can be used to handle network communication
o n behalf of a service, offloading c o m m o n connectivity tasks
(see § 5.2)
3. A n Anti-Corruption Layer, although it does not necessarily need to
be colocated, will still benefit from close proximity to at least one of
the involved parties (see § 11.1)
8.3 Aggregating Gateway
Aggregate multiple service requests into a single client response
This pattern is based on Newman's Central Aggregating Gateway [3, p. 475],
Microsoft's Gateway Aggregation [49] and Richardson's API Composition,
specifically its implementation i n a service [20, p. 221].
The last of the roles of a central gateway (defined i n § 4.1) is to coordinate
and aggregate multiple service responses, but i n contrast to Offload to
Gateway (§ 5.3), this acts for the benefit of the clients. While this pattern is
a distributed equivalent of the well-known facade pattern, it has different
corollaries and is worth mentioning separately.
70
8. P E R F O R M A N C E A N D L A T E N C Y P A T T E R N S
8.3.1 Context
Clients need data from multiple services, and there is a need for at least one
of the following.
1. Reduce the complexity of the client by offloading the aggregation
or filtering logic to the gateway.
2. Reduce network usage with the client if the amount of data is larger
than the aggregate and the gateway, especially i f the gateway is near
the services.
3. Decrease latency and improve reliability if the data has to be transmitted
over an unreliable or high-latency network, such as over mobile
networks, as each new request adds to the latency and increases
the likelihood of failure.
4. Decrease coupling between the client and the services
8.3.2 Solution
Extend a Gateway Router (see § 4.1) with a Facade (see [24, p. 175]). Instead
of a client sending multiple requests to different services to ask for the
resources it needs to construct the result, it asks directly for the result (see
fig. 8.3).
To also effectively combat network latency and reliability issues, the
gateway needs to have a better link to the services than the client.
8.3.3 Potential issues
Overuse of this pattern has similar effects as the overuse of Offload to
Gateway (see § 5.3), namely b e c o m i n g a development and performance
bottleneck and a single point of failure, and handling too many concerns.
8.3.4 Example
See the example i n Backend for Frontend (see § 5.4.4).
8.3.5 Related patterns
• If only no aggregation is needed, Gateway Routing can still be used
to abstract service locations (see § 4.1)
• After an aggregator is placed, it might be beneficial to offload shared
functionality to it using Offload to Gateway (see § 5.3) - however,
see the note i n § 4.1.7
71
8. P E R F O R M A N C E A N D L A T E N C Y P A T T E R N S
Client
Figure 8.3: Aggregating Gateway
If the need for server-side aggregation comes from differing needs
of clients, Backend for Frontend [BFF) can be instead utilised to
effectively combat the complexity of the aggregator (see § 5.4)
8.3.6 Further Reading
• M a r t i n Fowler's Remote Facade [7, p. 388, 136] is a very similar
pattern that applies the same logic but just to one service, aggregating
multiple calls to one
8.4 Claim Check
Reduce message sizes by storing large payloads externally
This pattern is based o n Claim Check by H o h p e et al. [4, p. 305, 137] and
Microsoft [138].
72
8. P E R F O R M A N C E A N D L A T E N C Y P A T T E R N S
8.4.1 Context
Two parties need to pass messages w i t h data payloads through a network,
messaging system (see § 4.2.7) or other services. None of these intermediaries
need to access the payload, and at least one of the following holds.
• Its size causes unecessary load or resource usage, causes the i n termediaries
to become a bottleneck, or simply does not fit into the
message
• The payload contains sensitive information that should not be exposed
to the intermediaries
8.4.2 Solution
Add a data store that is accessible to both communicating parties. The producer
stores the payload i n the store w i t h an associated unique key - the
claim-check token. It then sends the message w i t h the token instead of
the payload. U p o n receiving the message, the consumer uses the token to
retrieve the payload from the store (see fig. 8.4).
eExternal Data Store Message Queue
Generates claim
check token
Stores payload
with token
"0
Sends message
with token
HForwards message
with token
Retrieves payload
with token
Payload
3
Figure 8.4: Claim Check
73
8. P E R F O R M A N C E A N D L A T E N C Y P A T T E R N S
The system can also conditionally store the payload based o n the size,
content, or other criteria to minimize round-trips to the data store i f it is not
necessary.
8.4.3 Potential issues
Failures m a y make payloads pile u p i n the storage system. Strategies for
garbage collection or time-to-live need to be defined. The storage system
can also become a bottleneck or a single point of failure i f additional
measures are not taken.
This pattern may also require tuning to find the balance between throughput
and latency and introduce additional complexity into the communica-
tion.
8.4.4 Example
ExampleEshop (see §3.4) messaging queues to handle review processing
(see § 6.2.4). However, the reviews can contain large files, such as images
or videos, w h i c h overwhelm the messaging system during large events. To
address this, the system saves the files to a separate data store before adding
the message to the queue. The message only contains a reference to the file,
w h i c h allows the system to handle m u c h larger backlogs.
8.4.5 Related patterns
• A n o t h e r way to use transactional storage is w i t h a Transactional
Outbox to ensure message delivery (see § 10.2)
8.5 Command and Query Responsibility
Segregation (CQRS]
Isolate data store reads and writes to prevent contention
This pattern is based on Command and Query Responsibility Segregation
by Richardson [20, p. 228,139], and Microsoft [140]. It was originally defined
by Dahan [141] and popularised by Young [142,143,144].
74
8. P E R F O R M A N C E A N D L A T E N C Y P A T T E R N S
8.5.1 Context
1. Reading data is inefficient, either because it is aggregated from
many sources, need expensive joins or transformations, possibly
of many kinds
2. Reads and writes are asymmetrical, leading to a need for separation
of concerns due to performance, security, or resilience (see § 7.1)
requirements
3. Reads and writes are contentious
8.5.2 Solution
Split the data store and a l l associated operations into two partitions: commands
for mutating the data and queries for reading the data. U p o n processing
commands, the c o m m a n d side publishes an event that is eventually
consumed by the query side to update the read model (see fig. 8.5).
Figure 8.5: C o m m a n d and Query Responsibility Segregation (CQRS)
The data stores can reside i n the same database but can also be physically
separated or use different technologies.
The original semantics o f the c o m m a n d s focused o n the intent of the
operation, not the data [141,142]. Richardson uses a looser interpretation,
75
8. P E R F O R M A N C E A N D L A T E N C Y P A T T E R N S
even mentioning the command-side services handling all the C R U D 4
operations
- including (simple) queries - focusing instead o n separate models
[20, p. 233]. Others offer this k i n d of solution as a separate pattern, such as
Fowler's Reporting Database [145] or Microsoft's Materialized View/ [126].
8.5.3 Potential issues
This pattern is difficult to use w e l l a n d can add unneeded complexity.
Consider only using this pattern i f the benefits outweigh the risks. For most
systems, a CRUD-based approach is both sufficient and more natural. If such,
shield the consumers from the underlying implementation. [3, p. 435, 143]
If eventual consistency is employed between the models, it can cause
consistency problems i f a single client updates data and then tries to query
it immediately afterwards. Possible solutions include supplying a warning if
the data is currently not up-to-date or having the client update a local copy
of the data [20, p. 236].
8.5.4 Example
ExampleEshop (see § 3.4) implements its o w n product catalogue. However,
the reads a n d writes to this catalogue differ, sometimes by orders o f magnitude.
Furthermore, reads require expensive joins and aggregations, as the
product page displays many different kinds of data. Fortunately, there is no
requirement for strict consistency, as a small delay i n updating the product
page is manageable.
To address this, the product catalogue uses a separate read database. This
database has several prepopulated views of products for different use cases,
such as the product page or the search page. A n y aggregations, filters or
transformations are pre-applied.
8.5.5 Related patterns
This pattern directly facilitates (and is often used w i t h [3, p. 434]) Event
sourcing (see § 10.6).
8.5.6 Further reading
• Fowler's thoughts on CQRS [143] and Event-Driven Architecture [39]
• Newman's thoughts on CQRS and Event Sourcing [3, p. 434]
• Wikipedia [144]
4. Create, Read, Update a n d Delete [38]
76
8. P E R F O R M A N C E A N D L A T E N C Y P A T T E R N S
The read-only nature o f the query can be used for several different
purposes. Unfortunately, even though their purpose is similar, they differ
enough i n structure not to be easily merged into a single pattern.
1. Fowler's Reporting Database focuses only on the read-only replica
to improve performance and scalability (something Richardson sees
as a part of CQRS) [145]
2. Richardson's Command-side replica moves the read-only store to
the client side to relieve stress on a providing service [146]
3. Microsoft's Materialized View [126] adds several command handlers,
generalising the w e l l - k n o w n database feature to distributed data
stores
77
9 Security Patterns
Security is a broad topic a n d m a n y patterns have been created to address
it, such as i n [147]. However, w h i l e most of t h e m do pertain to distributed
systems, few are focused on the architecture of the system itself. This chapter
presents a few useful patterns for enhancing the security of a distributed
system directly through its architecture.
1. The Identity Provider & Federated Identity patterns i n § 9.1 shows
two c o m m o n ways to handle authentication and authorization i n a
distributed system
2. The Gatekeeper pattern i n § 9.2 instead uses distribution to its advantage
to isolate security incidents i n a limited environment
Other patterns that could be considered part o f this category include
[148]:
• Ambassador (see § 5.2) and Offload to Gateway (see § 5-3) can be
used to improve network security, especially i n legacy systems
• Bulkheads (see § 7.1) can be used to limit the blast radius of a security
incident
• Claim Check (see § 8.4) can be used to protect sensitive data i n communication
by hiding them i n a secure data store
Notable omissions i n this category due to the methodology described i n
§ 1 include:
• Quarantine by Microsoft [149], as it is a process, not an architectural
pattern
• Valet Key by Wilder and Microsoft [14, p. 115,129] as it is only useful
in cloud environments
9.1 Identity provider & Federated Identity
Centralise authentication to reduce the attack surface
This pattern is based on Identity Provider by Delessy et al. [150] and RotemGal-Oz
[13, p. 91], Federated Identity by Delessy et al. [150] and Microsoft
[151], and Access Token by Richardson [20, p. 354,152].
78
9. S E C U R I T Y P A T T E R N S
9.1.1 Context
Services need to verify the authorisation o f requests. Implementing this
i n each service can lead to the following problems, each decreasing the
system's security.
1. Code duplication increases the attack surface, as each service
needs to implement the same logic
2. Users may need to manage multiple identities, w h i c h reduces usability
and increases password fatigue1
3. Added complexity i n user management and access control leads to
more potential security vulnerabilities
9.1.2 Solution
Implement or employ an Identity Provider to centralise authentication and
authorisation. Once a user is authenticated, the identity provider issues an
access token that can be used to verify the user's identity or more granular
permissions (see fig. 9.1). This token can be either:
1. Opaque - to verify the authenticity of the token, the service must
query the identity provider to check the token's validity
2. Transparent - the token is cryptographically signed, allowing the
service to verify the token's authenticity independently
The client can retrieve the token from the identity provider directly, or
a gateway can facilitate c o m m u n i c a t i o n (see § 5.3). The identity provider
can transitively trust other providers, allowing for single sign-on across
multiple services (also called afederated identity).
9.1.3 Potential issues
Using a single identity provider can lead to a single point of failure, both i n
terms of security and availability. This risk can be lowered by using federated
identity providers, but this, i n turn, results i n the trade-off of increasing the
chance of failure and having to trust multiple, possibly external, providers.
Implementing authorisation i n a gateway naively without tokens can
lead to the Confused Deputy Problem. A Confused Deputy is a specific type of
1. Password fatigue is a w i d e l y used t e r m to describe the heavy cognitive load o f m a n a g i n g
m u l t i p l e passwords resulting i n relaxed security practices [153,154,155]
79
9. S E C U R I T Y P A T T E R N S
Authenticates
and retrieves token
Identity
Provider
Client
Authorises
with token
• Trusts
Can be part of
a federation with
Service
1
l \
I External 1
i Identity Providers 1
Figure g.i: Identity Provider & Federated Identity
privilege escalation attack where an intermediary is tricked into performing
actions o n behalf of an attacker [156,157]. This can happen as downstream
services do not verify the authorisation of requests. Due to this implicit trust,
an attacker w o u l d only need to trick a single service i n a call chain to get
access to unauthorised data. [3, p. 380]
9.1.4 Example
ExampleEshop (see §3.4) offers a n employee discount program. To access
this program, employees need to log i n using their company email address,
but this account also needs to be tracked and terminated when the employee
leaves the company. However, they do not want to store the whole employee
identity database i n the eshop, as this w o u l d introduce a security risk. Instead,
they deploy two identity providers i n a federation. T h e public a n d
private parts of the system use their o w n providers, but the public one trusts
the private one, w h i c h allows it access to the employee's name, e m a i l a n d
affiliation.
9.1.5 Further reading
• Sam N e w m a n o n c o m m o n single sign-on implementations i n Building
Microservices [3, p. 377]
80
9. S E C U R I T Y P A T T E R N S
• Identity providers [158] and Federated identities [159] on Wikipedia
9.2 Gatekeeper (Service Firewall)
Protect services by validating and sanitising incoming requests in a
limited environment
This pattern is based Service Firewall by Rotem-Gal-Oz [13, p. 35] and Gatekeeper
by Microsoft [160]. It can be seen as a variation of Firewall Proxy by
Buschmann et al. [54].
This w o r k adopts the newer Gatekeeper name to provide a distinction
between traditional firewalls.
9.2.1 Context
A service or a resource needs to be secured from malicious requests from
external clients, as a vulnerability could potentially give an attacker access
to sensitive internal resources or disrupt the service.
9.2.2 Solution
This situation can be improved by deploying a gateway service to a limited,
isolated environment. This service acts as an intermediary between the
clients and the internal services, handling all incoming requests (see fig. 9.2).
Client
Restricted Environment
Request
Gatekeeper
Internal Services
Validated & sanitized
request
Service
Figure g.2: Gatekeeper (Service Firewall)
The gatekeeper validates and sanitises the requests, depending o n the
requirements. It does not perform any additional processing. W h e n encountering
a problematic request, it can be audited and logged for later analysis.
If the gatekeeper gets breached, the environment limits the blast radius
of the attack, as the internal services and resources are shielded from direct
access.
81
9. S E C U R I T Y P A T T E R N S
9.2.3 Potential issues
The gatekeeper introduces additional complexity and latency to the system,
w h i c h can decrease performance, depending o n the i m p l e m e n t e d
functions. It can also act as a single point of failure or bottleneck i f no
additional measures are taken to ensure its availability.
9.2.4 Example
ExampleEshop (see §3.4) allows users to create accounts or post reviews.
This means accepting and storing user-generated content, w h i c h can lead
to security risks. To address this, the system uses gatekeeper services to
validate all content entering the system. For instance, it sanitises all text to
defend against XSS attacks2
, or checks for k n o w n vulnerabilities i n uploaded
files.
It also includes a rate limiter to prevent abuse and a honeypot3
. Since it
exists i n an isolated environment and sees only a limited number of (secured)
endpoints, the gatekeeper acts as a first line of defence against attacks. This
limited environment can be easily m o n i t o r e d and audited, so the attacker
does not automatically get access to secrets or sensitive data i n the event of
a breach.
9.2.5 Related patterns
• This pattern can be seen as a specialisation of Offload to Gateway
(see § 5-3) or Ambassador (see § 5.2)
2. Cross-site scripting (XSS) is a (slightly confusing) n a m e for a type o f security vulnerability
that enables JavaScript injection, thereby being able to manipulate the content o f a w e b page
or access sensitive data [161]
3. A honeypot is a security m e c h a n i s m designed to look like a vulnerable part of the system
to attract attackers a n d l o g their actions [162]
82
io Consistency Patterns
This chapter details patterns that help to ensure consistency i n distributed
systems.
1. The Transaction-Based Processor i n § 10.1 expands w e l l - k n o w n
database transaction to message processing
2. The Transactional Outbox i n § 10.2 ensures messages are sent i f a
database is updated
3. The Saga pattern i n § 10.3 shows a way h o w to manage distributed
transactions, a notoriously difficult p r o b l e m . It has two possible
implementations:
1. Choreography i n § 10.4 where services communicate directly
2. Orchestration i n § 10.5 where a central service manages the
process
4. The Event Sourcing pattern i n § 10.6, a well-known pattern that can
also be used to simplify consistency i n an event-driven architecture
Other patterns that could be considered a part of this category include:
• Queue-Based Load Levelling (see § 7.2) which can be used to achieve
guaranteed delivery of messages
• Publisher-Subscriber (see § 4.2) to facilitate data replication w h e n
using event sourcing
• Leader and Followers (see §7.6) w h i c h is c o m m o n l y used i n data
replication [5, p. 85]
• Command and Query Responsibility Segregation (CQRS) (see § 8.5)
which can be used to implement event sourcing, but also to introduce
eventual consistency
Notable omissions i n this category due to the methodology described i n
§ 1 include:
• Data Abstractor by Fehling et al. [15, p. 194], which is not mentioned
by any other authors
• Command-side replica by Richardson [146] for the same reason
• Domain Event by Richardson [20, p. 160] as it does not pertain to
architecture
83
10. C O N S I S T E N C Y P A T T E R N S
10.1 Transaction-Based Processor
Use transactions to encapsulate atomic processes
This pattern is based o n the Transaction-Based Processor by Fehling et
al. [15, p. 201,163], w h i c h i n t u r n generalises the Transactional Client by
Hohpe et al. [4, p. 431,164] and database transactions.
10.1.1 Context
Reading data f r o m message m i d d l e w a r e or updating data i n a database
transactionally is not enough, as it must depend on an associated process.
10.1.2 Solution
The transaction is extended to encompass the associated process.
1. The message is only deleted f r o m the queue once the operation is
successful
2. The changed data is only committed to the database i f the operation
is successful
This extends the A C I D properties of the transaction to the associated
process (see fig. 10.1).
10.1.3 Potential issues
This pattern requires support i n the message middleware and the database
system.
10.1.4 Example
The distributed transaction used for handling orders i n ExampleEshop (see
§ 3.4) uses messaging queues (see § 7.2.4) to reliably communicate between
services and handle backlogs of messages. However, a service could still fail
while processing a message, e.g. the warehouse system c o u l d crash while
handling a reservation, and this reservation w o u l d be lost o n a restart. To
account for this, the services communicate with the broker transactionally.
W h e n receiving a message, the broker does not remove the message from
the queue; it only hides it and only removes it once it confirms that the
message was processed successfully.
84
10. C O N S I S T E N C Y P A T T E R N S
0Database
Transaction-Based
Data Processor
Start transaction
Read data
Write data
Commit transaction
Transaction-Based
Message Processor
Message
Queue
Process Process
data message
Read message
Message is kept
in gueue
H*
Delete message
Figure 10.1: Transaction-Based Processor
10.1.5 Related patterns
The Transactional Outbox combines these two approaches, guaranteeing a
message is sent i f a database is updated (see § 10.2).
10.2 Transactional Outbox
Atomically send a message and update the database
This pattern is based on the Transactional Outbox by Richardson [20, p. 97,
165] and Deenadayalan [166].
10.2.1 Context
A message a n d a database operation need to be done as part of the same
transaction - the message must be sent iff the operations succeed - a n d a
two-phase commit1
cannot be used, either because o f incompatibility w i t h
the underlying technologies, payload differences, or availability concerns
[20, p. 112,169].
1. A t w o - p h a s e c o m m i t is a p r o t o c o l that e n s u r e s that a l l p a r t i c i p a n t s i n a d i s t r i b u t e d
transaction agree o n w h e t h e r to c o m m i t o r abort the transaction [see 5, p. 257,167,168].
85
10. C O N S I S T E N C Y P A T T E R N S
1 0 . 2 . 2 Solution
Store the message i n the database as a part o f the transaction i n an outbox
table (see fig. 10.2). A n outbox processor reads messages from the outbox table
and sends t h e m to the message broker. The processor marks the messages
as sent or deletes t h e m to avoid reprocessing.
8 Outbox Processor^ ^ Queue
transaction 1
Update data
Add message
to outbox
Read outbox
GMessage
Send message
0^
Mark message
as sent
Figure 1 0 . 2 : Transactional Outbox
Richardson highlights two methods for i m p l e m e n t i n g the outbox pro-
cessor:
1. The Polling publisher periodically polls the database, trading simplicity
for increased load and traffic [20, p. 98,170]
2. The Transactional log tailing is a more efficient method w h i c h reads
the database's commit log and propagates that instead [20, p. 99,171]
10.2.3 Potential issues
Depending on the implementation, this can cause increased database load,
w h i c h can cause it to b e c o m e a bottleneck. It also introduces additional
complexity due to a need for an extra processor and additional latency i n
message delivery.
86
10. C O N S I S T E N C Y P A T T E R N S
This pattern does not prevent duplicate messages; handling those requires
additional measures.
10.2.4 Example
Example eshop (see § 3.4) needs to send a confirmation e m a i l w h e n users
register. If the confirmation email has not been delivered but the account has
been created, the user might need to ask for a password reset. To avoid this,
the service handling registration writes a message to an outbox as part of the
user creation database transaction. The message is not removed f r o m the
outbox until the service receives a confirmation that the e m a i l has arrived
or that the email address does not exist.
10.2.5 Related patterns
• If the transaction needs to span multiple services, use the Saga
pattern (see § 10.3)
• If there is no update to the database, using Queue-based Load Leveling
for guaranteed delivery might be more efficient (see § 7.2)
10.2.6 Further reading
• Inbox and Outbox pattern [58]
10.3 Saga
Sacrifice isolation for increased availability during a distributed
transaction
This pattern is based o n Saga by Garcia-Molina et al. [172]. A l t h o u g h originally
intended to implement long-living transactions (LLTs)2
, it has been
interpreted for use i n distributed systems i n general, see Rotem-Gal-Oz [13,
p. 129], R i c h a r d s o n [20, p. 114, 173], N e w m a n [3, p. 182], Richards et al. [2,
p. 261], Microsoft [174], and Deenadayalan [175].
10.3.1 Context
Multiple services need to participate i n a distributed transaction of a business
process, but other ACID algorithms, such as a two-phase commit, are
2. Transactions l o c k i n g resources i n a database f o r a l o n g time, c a u s i n g c o n t e n t i o n
87
10. C O N S I S T E N C Y P A T T E R N S
not a n option (see the context o f § 10.1 for m o r e details). Not having the
transaction isolated is an acceptable trade-off.
10.3.2 Solution
Break the long-lived transaction into smaller short-lived transactions. In the
case of a business failure, the system can apply either:
1. Forward recovery, b y retrying the transaction f r o m a particular
save-point, i f the failed operation was idempotent
2. Backward recovery, b y r u n n i n g compensating transactions to undo
the operations that were already performed
3. C o m b i n e both approaches based o n the context (see fig. 10.3) [3,
p. 189]
r N [successj f \ * L s u c c e s s
J f
@ M Operation 1 j *{ Operation 2 j ~~" *{
[failure]
[failure] [failure]
Compensating
Transaction 1
Compensating
Transaction 2
Fail-backward Fail-forward
Figure 10.3: Saga
Executing steps with a high probability of failure can decrease the amount
of compensating transactions needed i n case of a failure [3, p. 188].
There are two possible ways to i m p l e m e n t a saga: Choreography, a n
event-driven approach suitable p r i m a r i l y for simpler sagas (see § 10.4), o r
Orchestration (see § 10.5). It m a y also be possible to nest these two styles
based o n the requirements of the process [3, p. 194,176].
10.3.3 Potential issues
If possible, always avoid distributed transactions, as it introduces a large
amount of additional complexity to the system [3, p. 181, 2, pp. 132, 260, 20,
p. 114].
Not all business operations c a n be fully rolled back. The compensating
transactions thus have to be semantic rollbacks, i.e. roll back enough i n the
context of the saga [3, p. 187]. These can be difficult to design [177,18:20].
88
10. C O N S I S T E N C Y P A T T E R N S
Since the saga is only A C D 3
, isolation needs to be handled separately
[see 20, p. 126 for c o m m o n approaches].
A c o m m o n misconception is that a saga can handle technical failures.
Different mechanisms are needed to handle such cases, such as Retry (see
§ 7.3) or sacrificing availability, e.g. with a two-phase commit [178].
10.3.4 Example
Order processing i n ExampleEshop (see § 3.4) is a complex process that i n volves
multiple services. W h e n a user places an order, the system needs to
check the availability of the products, reserve them, charge the user, notify
the warehouse, and send a confirmation email. If any of these steps fail, the
system needs to roll back the changes and notify the user.
The steps i n the saga are ordered to minimize the compensating transactions
needed by running the step most likely to fail first.
1. Charge the user (checkpoint)
2. Send a confirmation email
3. Reserve all products
4. Send them out for delivery
The payment marks a checkpoint from w h i c h the system proceeds with
forward recovery. If not all products are i n stock, the system can notify the
user a n d retry once the products are available again. Alternatively, i f the
customer decides to cancel the order, the system can undo the reservation
and issue a refund.
10.3.5 Related patterns
• Event Sourcing (see § 10.6) can be used to implement compensating
transactions [2, p. 132]
10.3.6 Further reading
• Compensating Transaction by Microsoft [95]
• Long-running Transactions [179] and Compensating Transactions [180]
on Wikipedia
3. M i s s i n g the " I " f r o m A C I D (see § 3.1)
89
10. C O N S I S T E N C Y P A T T E R N S
10.4 Choreography-Based Sagas
Distribute responsibility for a saga across participating services
This pattern is based on Choreography by Richardson [20, p. 118,173], Newm
a n [3, p. 192], Microsoft [174] and Deenadayalan [181].
Hohpe et al. [4, p. 284] consider this a distributed Pipes and Filters.
10.4.1 Context
A Saga needs to be implemented (see § 10.3), and the interactions between
services are simple or few. The services need to be autonomous and have
local control. A central orchestrator (see § 10.5) would be an unwanted single
point of failure i n the system.
10.4.2 Solution
Services pass each other events using Publisher-Subscriber (see §4.2) or
Queue-Based Load Levelling (see § 7.2). They move the transaction forward
on receiving successful events and roll back o n receiving failure events (see
fig. 10.4).
Figure 10.4: Choreography-based Saga
10.4.3 Potential issues
Using choreography means n o single place documents the entire process,
w h i c h may make it hard to understand. This can make it unsuitable for
complex sagas.
It c a n also m a k e it harder to monitor the state of the process - one
solution is to use a Correlation Identifier [4, p. 154, 63] and log all events
passed through the system [3, p. 193].
Regarding development, choreography can lead to cyclic dependencies
or tighter coupling between services [20, p. 121].
90
10. C O N S I S T E N C Y P A T T E R N S
10.4.4 Example
ExampleEshop (see § 3.4) screens and compresses attachments i n a review.
This process is composed of several steps and needs to be separated into different
services, either because of security (see § 9.2.4) or different hardware
requirements.
1. The review attachment repository saves the attachment and creates
a new message with a Claim Check (see § 8.4) token
2. The spam and inappropriate content filter checks the attachment
3. The image processing service compresses the attachment
4. The review is added to the database
The services communicate with each other using a message broker (see
§ 4.2) and subscribe to the events needed to move the process forward (see
fig. 10.5).
Figure 10.5: Product review processing using a choreographed saga
10.4.5 Related patterns
• Orchestration i f the interactions are c o m p l e x or there are many
services (see § 10.4)
91
10. C O N S I S T E N C Y P A T T E R N S
10.5 Orchestration-Based Sagas
Centralise responsibility for a saga in a single service
This pattern is based on the original behaviour of Sagas [172], and defined
as Orchestration by Rotem-Gal-Oz [13, p. 170], Richardson [20, p. 121,173],
N e w m a n [3, p. 189], Azure [174], and Deenadayalan [182].
Process Manager by Hohpe et al. [4, p. 278], l/Vorkflodize by Rotem-GalOz
[13, p. 35], and Scheduler Agent Supervisor by Microsoft [183] implement
a similar concept but do not discuss failure management; i f such they imply
failing-forward.
10.5.1 Context
A Saga (see § 10.3) needs to be implemented, but the interactions between
services are complex, many in number, or need to be independent. It is
desirable to have the workflow defined and monitored i n a single place.
10.5.2 Solution
Implement or appoint a central Orchestrator that operates a state machine
describing the saga (see fig. 10.6). The orchestrator sends commands to
the services involved i n the saga, instructing t h e m o n what to do next. The
services then respond with the outcome of the operation.
10.5.3 Potential issues
Using an orchestrator m a y lead to increased coupling between it and the
services. I m p l e m e n t i n g it as a n e w service to manage the saga leads to
increased complexity. The orchestrator can become a single point of
failure and introduces a risk o f centralising business logic i n a single
service.
10.5.4 Example
As the order processing i n ExampleEshop (see § 3.4) involves a complex process
and multiple services, they decided to use a central orchestrator to
manage the process. The orchestrator is responsible for coordinating the
services a n d triggering compensating transactions i n the case of a failure
by i m p l e m e n t i n g a state m a c h i n e . This way, the process is readable and
easily changed or extended. As it waits for external services for most of the
process, the orchestrator uses asynchronous programming to r u n multiple
92
10. C O N S I S T E N C Y P A T T E R N S
Figure 10.6: Orchestration-based Saga
sagas concurrently. It also logs each step (see § 10.6.4) i n the process, which
can be used for debugging or analytics.
10.5.5 Related patterns
• Choreography if the n u m b e r of services is small (see § 10.4)
10.6 Event Sourcing
Store data as a sequence of changes to preserve history
This pattern is based on Event Sourcing by Fowler [184], later by Richardson
[20, p. 184,185], N e w m a n [3, p. 434], Microsoft [186] and Deenadayalan [187].
10.6.1 Context
See the context defined i n 10.2.1. Furthermore, the application would benefit
from storing the entire history of state changes due to one of the following
reasons [184].
93
10. C O N S I S T E N C Y P A T T E R N S
1. The history needs to be (or w o u l d benefit from being) auditable or
analysed, and as such there needs to be a high level of trust i n the
log
2. It needs to be able to reconstruct the state at any given time or
analyse the impact of changes
3. The application would benefit from r u n n i n g in-memory due to performance
requirements
10.6.2 Solution
Implement the Command and Query Responsibility Segregation (CQRS)
(see § 8.5) pattern. O n top of it, store each event change as a separate record
in an append-only event store (see fig. 10.7).
Sends command
Command
Handler
Client
Queries data
f, ^ ^ Projection
l 1«
. Read Model .
Appends event
Appent-Only
Event Store
Figure 10.7: Event Sourcing
10.6.3 Potential issues
W o r k i n g with an event-sourced system m a y be unfamiliar and thus have a
learning curve. Communication with external system needs to be carefully
handled i f needing to replay the history, such as deterministic identifier
generation. Schema evolution and deleting data can also be challenging.
94
10. C O N S I S T E N C Y P A T T E R N S
10.6.4 Example
ExampleEshop (see § 3.4) employs a backend system to manage products. On
change, this system triggers a rebuild of the read-only database replicas (see
§ 8.5.4). Since rebuilding the whole database is expensive, the system only
sends the changes to the replicas. However, an issue arises w h e n a replica
fails, as without a history of the changes, it is hard to tell w h i c h changes
have already been applied, and a full rebuild has to be triggered, prolonging
the downtime.
To address this, the system uses event sourcing, as it is already using
CQRS. Each replica holds the event it has processed last, and w h e n it fails,
it only needs to request the events it has missed. This way, the system can
recover m u c h faster. This also has business benefits, as the system can now
provide a history of changes, w h i c h can be used for analytics or to recover
from user errors.
Another point where the system uses event sourcing is i n the order
processing orchestrator (see § 10.3.4). This allows for easy transactional
messaging between services, as the orchestrator can simply replay the events
if a service fails, and simplifies debugging i n the event that a transaction
fails, w h i c h is important as a problem i n the order processing can result i n
significant financial losses.
10.6.5 Related patterns
• Command Query Responsibility Segregation (CQRS) can facilitate
event sourcing by splitting read and write operations beforehand
(see § 8.5)
10.6.6 Further Reading
• Sam Newman's thoughts on CQRS and Event Sourcing [3, p. 434]
• Event-driven architecture on Wikipedia [188]
95
ii Migration and Compatibility Pat-
terns
This chapter presents patterns for working with legacy, external or incompatible
systems.
1. The Anti-Corruption Layer pattern i n § 11.1 is a way to isolate somehow
corrupted (i.e. poor or incompatible) design of other services
2. The Incremental Replacement (Strangler Fig) pattern i n § 11.2
shows how to replace a legacy system piece by piece
3. The Messaging Bridge pattern i n § 11.3 connects two systems with
incompatible messaging middleware
Other patterns that could be considered part of this category include:
• Ambassador (see § 5.2) and Sidecar (see § 5.1), which can be used to
extend the functionality of (legacy) services
Other patterns for migrating monolithic systems are already described
in depth by N e w m a n [189].
ii.i Anti-Corruption Layer [ACL]
Mediate between modern and legacy systems
This pattern is based o n the Anticorruption Layer1
defined by Evans [190,
p. 364], later by R i c h a r d s o n [20, p. 446, 191], Deenadayalan [192] and M i crosoft
[193].
It has a similar notion to the Adapter2
pattern by Burns [65, later 22,
p. 31], although the latter focuses predominantly o n its usage i n regards to
enabling Health Monitoring (see § 7-4) and is deployed as a Sidecar (see
§5.1).
Fowler's Gateway [7, p. 466] can be seen as an implementation of this
pattern [194,195].
1. Not to be c o n f u s e d w i t h Access C o n t r o l Lists, w h i c h have the same a c r o n y m
2. Not to be c o n f u s e d w i t h the w e l l - k n o w n Adapter p a t t e r n b y G a m m a et al. [24]
96
11. M I G R A T I O N A N D C O M P A T I B I L I T Y P A T T E R N S
11.1.1 Context
A n application needs to w o r k w i t h an external system that satisfies one of
the following conditions.
1. It uses outdated technologies that would bring i n unwanted dependencies
or are incompatible
2. It has a poorly designed (corrupted) A P I
3. It is impractical to change (e.g. a legacy system)
4. It uses different model semantics
11.1.2 Solution
Implement an anti-corruption layer that isolates the two systems, acting as
an intermediary that translates between them.
This layer can be a separate software or a different service (see fig. n . i ) .
Modern System
Adapted
domain
> Anti-Corruption Layer
domain
Legacy SystemLegacy System
Figure n.i: Anti-corruption layer (ACL)
11.1.3 Potential issues
A n y data transformation inevitably causes increased increased latency.
W h e n scaling the system up, the A C L may become a bottleneck or a single
point of failure. If the u n d e r l y i n g service is scalable, the A C L has to be
designed with that i n m i n d .
If the A C L is implemented as an additional service, it adds maintenance
cost. Furthermore, if it is a short-term solution, the A C L needs to be tracked
as technical debt.
Lastly, there is a risk of persisting corruption - if the API of the A C L is
poorly designed, the "corruption" w i l l be propagated anyway.
11.1.4 Example
ExampleEshop (see § 3.4) uses an old warehouse system to manage its inventory.
However, this warehouse system is old, uses legacy technologies and has
97
11. M I G R A T I O N A N D C O M P A T I B I L I T Y P A T T E R N S
a c o m p l e x API i n a foreign language. To decrease coupling a n d to prevent
having to p u l l i n legacy dependencies, the eshop uses a n anti-corruption
layer to translate between the two systems. This layer provides an API that
uses the same semantics as the rest of the system, so developers w o r k i n g
on the eshop do not need to k n o w the intricacies of the warehouse system.
This also means that once this system is replaced, the rest of the system will
not need to be updated.
11.1.5 Related patterns
• The A C L can be deployed as a Sidecar for increased performance
(see § 5.1)
• The Incremental Replacement (Strangler Fig) pattern can be used
to phase out the underlying system and A C L gradually (see § 11.2)
• A Messaging Bridge can be used i f systems use incompatible messaging
systems (see § 11.3)
11.1.6 Further Reading
• If there is no underlying issue with the system you want to adapt, the
Facade [24, p. 175,196], Adapter [24, p. 139,197] and Mediator [24,
p. 273,198] patterns may still be applicable
• Fowler's example on how to use the anti-corruption layer to refactor
code w o r k i n g with external services [194]
11.2 Incremental Replacement (Strangler Fig]
Replace a legacy system step-by-step
This pattern is based on the Strangler Fig Application originally defined by
Fowler [199, later 200], later by Richardson [20, p. 430, 201], N e w m a n [189,
p. 79, 3, p. 79], Deenadayalan [202] and Microsoft [203].
Fowler later renamed the pattern to Strangler Fig, as it was c o m m o n l y
shortened to strangler application - which had a violent connotation, different
to the original plant-based metaphor [204] - i n hopes of strengthening the
original intention of the name [199].
98
11. M I G R A T I O N A N D C O M P A T I B I L I T Y P A T T E R N S
In this spirit3
, this w o r k p r i m a r i l y refers to this pattern w i t h the more
descriptive Incremental Replacement, avoiding the metaphor altogether so
as not to depend on the reader's prior botanical knowledge.
11.2.1 Context
For whatever reason, a legacy system needs to be replaced, but a big bang4
release w o u l d bring unnecessary risks.
11.2.2 Solution
A d d Gateway Router (see § 4.1) before the legacy and new applications.
Initially, the router forwards all requests to the legacy system. Over time,
it filters out requests that can be handled by the new system, gradually
replacing the legacy system w i t h the new one (see fig. 11.2).
Client
Gateway Router
New Application
(Strangler Fig) Legacy Application
Sends request
Response
alt ; [feature implemented] !
Process request in \
the new application !
« *.u[else] :
Fall back to the I
legacy application ;
*ri• • 1
Figure 11.2: Incremental Replacement (Strangler Fig)
This spreads both the risk and the development effort over time. Parallel
Run [189, p. 79] - i.e., r u n n i n g can ensure the n e w system emits the same
behaviour as the legacy system before switching over.
3. Fowler h i m s e l f admits he has n o objection to changing the n a m e but opted to strengthen
instead the original m e t a p h o r as he h a d doubts w h e t h e r it w o u l d catch o n
4. Big bang adoption is a t e r m c o m m o n l y u s e d to d e s c r i b e r e p l a c i n g a n entire s y s t e m at
once, w h i c h often leads to p r o b l e m s [205]
99
11. M I G R A T I O N A N D C O M P A T I B I L I T Y P A T T E R N S
Once the migration is complete, the router can be phased out, or it can
be used as an Anti-Corruption Layer adapter (see § 11.1) for legacy clients.
11.2.3 Related patterns
• This pattern can be seen as a message-based temporary Gateway
Router (see § 4.1)
• For c o m m u n i c a t i n g w i t h a legacy system, consider using a AntiCorruption
Layer to isolate legacy d o m a i n logic a n d models (see
§ 11.1)
11.2.4 Example
ExampleEshop (see § 3.4) is w o r k i n g o n i m p l e m e n t i n g same-day delivery to
improve its competitiveness. However, the technical limitations of the old
system it uses i n manage its warehouses (see § 11.1) prevent the implementation
of this goal. Furthermore, since the original author left, the company
lacks the necessary expertise with the system's legacy technologies to facilitate
the needed changes.
The company has decided to implement a new warehouse management
system to address this. However, this system is critical to business, and the
company cannot afford the risk of a sudden switch. Instead, they decide to
i m p l e m e n t the n e w system gradually. They start by first r e i m p l e m e n t i n g
enough features to handle same-day delivery. Once this is done, the system
is tested i n parallel m o d e to see i f it produces the same results as the old
system. It is deployed to handle same-day delivery for a select subset of
items i f it proves stable.
Even though the n e w system cannot fully replace the o l d one yet, it
already provides business value and can be gradually expanded with more
features without time pressure.
11.2.5 Further reading
• Newman's book o n migrating legacy systems to microservices contains
many other useful patterns [189, p. 113]
100
11. M I G R A T I O N A N D C O M P A T I B I L I T Y P A T T E R N S
11.3 Messaging Bridge
Connect two services with incompatible messaging middleware
This pattern is based on Messaging Bridge defined by Hohpe et al. [4, p. 132,
206] and later by Microsoft [207], and Message Mover by Fehling et al. [15,
p. 225, 208].
11.3.1 Context
Two services need to c o m m u n i c a t e w i t h each other but use incompatible
messaging middleware. Linking them without changing (at least one of) the
underlying services is preferred.
11.3.2 Solution
Create a n e w service (or change one o f the existing parties) that acts as a
bridge between the two brokers. This service receives messages from one
broker and forwards t h e m to the other (see fig. 11.3).
Figure 11.3: Messaging Bridge
101
11. M I G R A T I O N A N D C O M P A T I B I L I T Y P A T T E R N S
11.3.3 Potential issues
Adding a bridge increases complexity and introduces an additional point
of failure and latency to the system.
The two brokers may also have incompatible features that need to be
reconciled.
11.3.4 Example
ExampleEshop (see § 3.4) wants to transition to a newer, more efficient messaging
system for its n e w services. However, this process takes time a n d
switching all services at once is unfeasible. To address this, the eshop deploys
a messaging bridge that translates messages between the old and new
systems. This allows t h e m to gradually migrate services to the new system
without updating the old services. Once all services are migrated, the bridge
is removed.
11.3.5 Related patterns
• See Publisher-Subscriber for more information o n message m i d dleware
(see § 4.2)
• The bridge may need to be scaled out using Competing Consumers
(see § 6.1)
• If the systems also have incompatible domains, consider using an
Anti-Corruption Layer (see § 11.1)
102
Conclusion
This thesis a i m e d to identify, catalogue and classify the most c o m m o n distributed
application architecture patterns i n a structured and accessible
way. It achieved this by conducting a comprehensive literature review and
defining a methodology for this purpose.
The result is an exhaustive catalogue of the 33 most c o m m o n patterns i n
this field, with thoroughly researched application criteria, advantages and
disadvantages, densely cross-referenced, and i n c l u d i n g custom-designed
visualisations and example use cases on a consistent d o m a i n .
These patterns are categorised to make them as easy as possible to navigate,
understand, and, most importantly, apply to solve specific problems. To
maximise this potential, the catalogue was fully transformed into a publicly
available website, h t t p s : / / j u r f . gi thub. i o/daap/.
103
Bibliography
1. FOWLER, M a r t i n . Design - W h o needs an architect? IEEE Software.
2003, vol. 20, no. 5, pp. 11-13. Available from DOl: 10.1109/MS.2003.12
31144.
2. RICHARDS, Mark; FORD, Neal. Fundamentals of Software Architecture:
An Engineering Approach. O'Reilly Media, 2020. ISBN 9781492043454.
3. NEWMAN, Sam. BuildingMicroservices, 2nd Edition. O'Reilly Media,
2021. ISBN 9781492034025.
4. HOHPE, Gregor; WOOLF, Bobby. Enterprise Integration Patterns:
Designing, Building, and Deploying Messaging Solutions. Addison-Wesley
Professional, 2003. Addison-Wesley Signature Series (Fowler), ISBN
978-0321200686.
5. J O S H1, U n m e s h . Patterns of Distributed Systems. Pearson Education,
2023. Addison-Wesley Signature Series (Fowler), ISBN 9780138222116.
6. KL 1M E s OVA, Lucie. Software Architecture Patterns and Design Principles
[online]. Brno, 2024 [visited on 2024-12-14]. Available from: https :
/ / i s .muni .cz/th/b64nq/. M A thesis. Masaryk University, Faculty of
Informatics. Supervised by Barbora BUHNOVA.
7. FOWLER, Martin. Patterns of Enterprise Application Architecture.
Addison-Wesley Professional, 2002. Addison-Wesley Signature Series
(Fowler). ISBN 978-O-321-12742-6.
8. FOWLER, Martin. Enterprise Integration Patterns [online], [visited on
2024-11-23]. Available from: https://martinfowler.com/books/eip.htin
I.
9. SCHMIDT, Douglas C ; STAL, Michael; ROHNERT, Hans;
BUSCHMANN, Frank. Pattern-Oriented Software Architecture,
Volume 2: Patterns for Concurrent and Networked Objects. Wiley, 2000.
ISBN 978-0-471-60695-6.
10. BUSCHMANN, Frank; HENNEY, Kevlin; SCHMIDT, Douglas C.
Pattern-Oriented Software Architecture, Volume 5: On Patterns and Pattern
Languages. Wiley, 2007. ISBN 978-0-470-61347-9.
11. NYGARD, M i c h a e l T. Release It!: Design and Deploy Production-Ready
Software. Pragmatic Bookshelf, 2007. ISBN 978-0-9787392-1-8.
104
BIBLIOGRAPHY
12. NYGARD, M i c h a e l T. Release It! Second Edition: Design and Deploy
Production-Ready Software. Pragmatic Bookshelf, 2018. ISBN 978-
1680502398.
13. ROTEM-GAL-OZ, A r n o n . SOA Patterns. M a n n i n g Publications, 2012.
ISBN 9781933988269.
14. WILDER, Bill. Cloud Architecture Patterns. O'Reilly Media, 2012. Develop
cloud-native applications, ISBN 9781449319779.
15. FEHLING, Christoph et al. Cloud Computing Patterns: Fundamentals to
Design, Build, and Manage Cloud Applications. Springer, 2014. Available
from DOl: 10.1007/978-3-7091-1568-8.
16. HOMER, Alex; SHARP, John; BRADER, Larry; SWANSON, Masashi
Narumoto Trent. Cloud Design Patterns: Prescriptive Architecture Guidancefor
Cloud Applications. Microsoft Developer Guidance, 2014. M i crosoft
patterns & practices, ISBN 978-1-62114-036-8.
17. MICROSOFT. Cloud Design Patterns [online]. 2024. [visited on
2024-10-22]. Available from: https : / / l e a r n . m i c r o s o f t . com / en - us
/ a z u r e / a r c h i t e c t u r e / p a t t e r n s / .
18. DEENADAYALAN, Anitha. Cloud design patterns, architectures, and
implementations [online]. A m a z o n Web Services, 2023-07-28 [visited
on 2024-10-22]. Available from: https://docs.aws.amazon.com/prescri
p t i v e - g u i d a n c e / l a t e s t / c l o u d - d e s i g n - p a t t e r n s / i n t r o d u c t i o n . h t m l .
19. NEWMAN, Sam. Building Microservices. O'Reilly Media, 2015. ISBN
9781491950357.
20. RICHARDSON, Chris. Microservices Patterns: With examples in Java.
Manning Publications, 2018. ISBN 978-1617294549.
21. RICHARDSON, Chris. A pattern language for microservices [online].
2024. [visited on 2024-10-20]. Available from: h t t p s : / / m i c r o s e r v i c e s
. i o / p a t t e r n s / .
22. BURNS, Brendan. Designing Distributed Systems: Patterns and
Paradigms for Scalable, Reliable Services. O'Reilly Media, 2018. ISBN
9781491983614.
23. HOHPE, Gregor. Conversation Patterns [online]. 2017-01. [visited on
2024-12-05]. Available from: https://www.enterpriseintegrationpatte
rns.com/patterns/conversation/index.html .
105
BIBLIOGRAPHY
24. GAMMA, Erich; H ELM, Richard; JOHNSON, Ralph; VLISSIDES, John.
Design Patterns: Elements of Reusable Object-Oriented Software. Pearson
Education, 1994. Addison-Wesley Professional Computing Series, ISBN
9780321700698.
25. WIKIPEDIA CONTRIBUTORS. Design Patterns [online]. Wikipedia,
The Free Encyclopedia, 2024 [visited on 2024-12-04]. Available from:
h t t p s : / / e n . w i k i p e d i a.org/w/i ndex.php?ti tle=Desi g n _ P a t t e r n s & o l d i d
=1254518953.
26. MARTIN, Robert C. Clean Code: A Handbook of Agile Software Craftsmanship.
Prentice Hall, 2009. ISBN 978-O-13-235088-4.
27. DAVID, A l i c i a Bailey; GLORE, Peyton. The Impact of Design and
Aesthetics o n Usability, Credibility, and Learning i n an Online Environment.
Online Journal of Distance Learning Administration. 2010,
vol. 13.
28. GUNN,Greg. How to Apply a Color Palette to Your Design - Tutorial
[online]. The Futur Academy, 2024 [visited on 2024-12-06]. Available
from: https://youtu.be/eXcKOqvi LEO.
29. WORLD WIDE WEB CONSORTIUM. Web Content Accessibility
Guidelines (WCAG) 2.2 [online]. 2023-10-05. [visited on 2024-12-06].
Available from: https://www.w3.org/TR/WCAG22/.
30. NOVOTNÝ, Vít. Using M a r k d o w n Inside TgX Documents. TUGboat
[online]. 2017, vol. 38, no. 2, pp. 214-217 [visited on 2020-07-31]. ISSN
0896-3207. Available from: https://tug.org/TUGboat/tb38-2/tbll9nov
otny.pdf.
31. MACFARLANE, John. Pandoc User'sGuide [online]. 2024-12-07. [visited
on 2024-12-16]. Available from: https://pandoc.org/MANUAL.pdf.
32. C o CKBURN, Alistair. Hexagonal Architecture [online]. 2005-01-04. [visited
on 2024-12-06]. Available from: h t t p s : / / a l i s t a i r.cockburn.us/he
x a g o n a l - a r c h i t e c t u r e / .
33. LUKÁŠOVA, Helena. Neverbální komunikace. Masaryk University.
FLPV123 Visual Communication. Available also from: https : / / i s
.muni.cz/el/fi/podzim2024/PV123/um/2024_02_reprezentace.pdf?pred
met=1642571.
34. SPEAR, A n d r e w D. E d m u n d Husserl: Intentionality and Intentional
Content. The Internet Encyclopedia of Philosophy [online]. [N.d.] [visited
on 2024-12-06]. ISSN 2161-0002. Available from: https://iep.utm.edu
/ h u s s - i n t / .
106
BIBLIOGRAPHY
35. HAERDER, Theo; REUTER, Andreas. Principles of transactionoriented
database recovery. ACM Comput. Surv. 1983, vol. 15, no. 4,
pp. 287-317. ISSN 0360-0300. Available from DOl: 10.1145/289.291.
36. WIKIPEDIA CONTRIBUTORS. ACID [online]. Wikipedia, The Free
Encyclopedia, 2024 [visited on 2024-12-05]. Available from: https://e
n.wikipedi a.org/w/i ndex.php?ti tle=ACID&oldi d=1250666732.
37. PRITCHETT, D a n . BASE: A n A c i d Alternative: In partitioned databases,
trading some consistency for availability can lead to dramatic
improvements i n scalability. Queue. 2008, vol. 6, no. 3, pp. 48-55. ISSN
1542-7730. Available from DOl: 10.1145/1394127.1394128.
38. WIKIPEDIA CONTRIBUTORS. Create, read, update and delete [online].
Wikipedia, The Free Encyclopedia, 2024 [visited on 2024-11-28]. Available
from: h t t p s : //en. wi k i pedi a. 0 rg/w/ i ndex. php?ti tle=C reate, _ rea
d,_update_and_delete&oldi d=1249739822.
39. FOWLER, M a r t i n . What do you mean by "Event-Driven"? [online].
2017-02-07. [visited on 2024-10-28]. Available from: https : / /martin
f o w l e r . c o m / a r t i c l e s / 2 0 1 7 0 1 - e v e n t - d r i v e n . h t m l .
40. MICROSOFT. Poison message handling [online]. 2023-03-30. [visited
on 2024-12-14]. Available from: https://learn.microsoft.eom/en-us/d
otnet/framework/wef/feature-details/poison-message-handling.
41. WIKIPEDIACONTRIBUTORS. Fallacies of distributed computing [online].
Wikipedia, The Free Encyclopedia, 2024 [visited on 2024-12-05].
Available from: h t t p s : //en. wi k i pedi a .org/w/i ndex. php?ti t l e = F a U a c i
e s _ o f _ d i s t r i buted_computi ng&oldi d=1253478356.
42. F o x , Armando; BREWER, Eric. Harvest, yield, and scalable tolerant
systems. In: Proceedings of the Seventh Workshop on Hot Topics in Operating
Systems. 1999, pp-174-178. Available from DOl: 10.1109/HOTOS.19
99.798396.
43. GILBERT, Seth; LYNCH, Nancy. Brewer's conjecture and the feasibility
of consistent, available, partition-tolerant web services. SIGACT
News. 2002, vol. 33, no. 2, pp. 51-59- ISSN 0163-5700. Available from
DOl: 10.1145/564585.564601.
44- RUMBAUGH, James; JACOBSON, Ivar; BOOCH, Grady. UnifiedModeling
Language Reference Manual, The (2nd Edition). Pearson Higher
Education, 2004. ISBN 0321245628.
107
BIBLIOGRAPHY
45- MICROSOFT. Gateway Routing pattern [online]. 2022-08-29. [visited
on 2024-10-22]. Cloud Design Patterns. Available from: h t t p s : / / l e a r n
.microsoft.com/en-us/azure/architecture/patterns/gateway-routing.
46. DEENADAYALAN, Anitha. API routing patterns [online]. Amazon Web
Services, 2023-07-28 [visited o n 2024-10-29]. C l o u d design patterns,
architectures, and implementations. Available from: https://docs.a
w s . a m a z o n . c o m / p r e s c r i p t i v e - g u i d a n c e / l a t e s t / c l o u d - d e s i g n - p a t t e r n s
/ a p i - r o u t i n g . h t m l .
47- HOHPE, Gregor; WOOLF, Bobby. Message Router [online]. 2003. [visited
on 2024-11-03]. Available from: https://www.enterprise!'ntegrati
onpatterns.com/patterns/messaging/MessageRouter.html.
48. HOHPE, Gregor; WOOLF, Bobby. Content-Based Router [online]. 2003.
[visited on 2024-12-16]. Available from: https://www.enterpriseintegr
ationpatterns.com/patterns/messaging/ContentBasedRouter.html.
49- MICROSOFT. Gateway Aggregation pattern [online]. 2022-07-28. [visited
on 2024-10-29]. Cloud Design Patterns. Available from: h t t p s : / / I
earn.microsoft.com/en-us/azure/architecture/patterns/gateway-agg
regation.
50. MICROSOFT. Gateway Offloading pattern [online]. 2022-07-28. [visited
on 2024-10-23]. Cloud Design Patterns. Available from: h t t p s : / / l e a r n
. m i c r o s o f t . c o m / e n - u s / a z u r e / a r c h i t e c t u r e / p a t t e r n s / g a t e w a y - o f f l o a d
ing.
51. RICHARDSON, Chris. Pattern: API Gateway/Backendsfor Frontends
[online]. 2024. [visited on 2024-10-23]. Available from: https://micros
e r v i c e s . i o / p a t t e r n s / a p i g a t e w a y . h t m l .
52. WIKIPEDIACONTRIBUTORS. API management [online]. Wikipedia,
The Free Encyclopedia, 2024 [visited o n 2024-12-16]. Available from:
h t t p s : / / e n . w i k i p e d i a . o r g / w / i n d e x . p h p ? t i t l e = A P I _ m a n a g e m e n t & o l d i d
=1258663368.
53. HOHPE, Gregor; WOOLF, Bobby. Publish-Subscribe Channel [online].
2003. [visited on 2024-11-03]. Available from: https://www.enterprise
i n t e g r a t i o n p a t t e r n s . c o m / p a t t e r n s / m e s s a g i n g / P u b l i s h S u b s c r i b e C h a n n
e l . h t m l .
54. BUSCHMANN, Frank; HENNEY, Kevlin; SCHMIDT, Douglas C.
Pattern-Oriented Software Architecture, Volume 4: A Pattern Language
for Distributed Computing. Wiley, 2007. ISBN 978-0-470-05902-9.
108
BIBLIOGRAPHY
55- MICROSOFT. Publisher-Subscriber pattern [online]. 2018-12-07. [visited
on 2024-10-29]. Cloud Design Patterns. Available from: h t t p s : / / l e a r n
. m i c r o s o f t . c o m / e n - u s / a z u r e / a r c h i t e c t u r e / p a t t e r n s / p u b l i s h e r - s u b s c
r i b e r .
56. DEE NA DAYA LAN, Anitha. Publish-subscribe pattern [online]. A m a z o n
Web Services, 2023-10-14 [visited o n 2024-10-29]. C l o u d design patterns,
architectures, and implementations. Available from: https ://d
o c s . a w s . a m a z o n . c o m / p r e s c r i p t i v e - g u i d a n c e / l a t e s t / c l o u d - d e s i g n - p a t
t e r n s / p u b l i s h - s u b s c r i b e . h t m l .
57. WIKIPEDIA CONTRIBUTORS. Publish-subscribe pattern [online].
Wikipedia, The Free Encyclopedia, 2024 [visited on 2024-12-16]. Available
f r o m : h t t p s : / / e n . w i k i p e d i a . org/w/index. php?title=Publish°oE2
?i80%93subscribe_pattern&oldid=124891452i.
58. WIKIPEDIA CONTRIBUTORS.Inbox and outbox pattern [online].
Wikipedia, The Free Encyclopedia, 2024 [visited on 2024-11-30]. Available
from: https://en.wi k i pedi a.org/w/i ndex.php?ti tle=Inbox_and_o
utbox_pattern&oldid=1260066808.
59- RICHARDSON, Chris. Pattern: Messaging [online]. 2024. [visited o n
2024-10-28]. Available from: https://microservices.io/patterns/comm
u n i c a t i o n - s t y l e / m e s s a g i n g . h t m l .
60. HOHPE, Gregor; WOOLF, Bobby. Request-Reply [online]. 2003. [visited
on 2024-11-01]. Available from: https://www.enterpriseintegrationpa
tterns.com/patterns/messaging/RequestReply.html.
61. MICROSOFT. Asynchronous Request-Reply pattern [online]. 2022-07-28.
[visited o n 2024-11-05]. Cloud Design Patterns. Available from: https:
/ / l e a r n . m i c r o s o f t . c o m / e n - u s / a z u r e / a r c h i t e c t u r e / p a t t e r n s / a s y n c - r e
q u e s t - r e p l y .
62. HOHPE, Gregor. Asynchronous Request-Response [online]. 2017-01. [visited
on 2024-12-05]. Available from: https://www.enterprise!'ntegrati
onpatterns.com/patterns/conversation/RequestResponse.html.
63. HOHPE, Gregor; WOOLF, Bobby. Correlation Identifier [online]. 2003.
[visited on 2024-12-02]. Available from: https://www.enterpriseintegr
a t i o n p a t t e r n s . c o m / p a t t e r n s / m e s s a g i n g / C o r r e l a t i o n l d e n t i f i e r . h t m l .
64. WIKIPEDIACONTRIBUTORS. Request-response [online]. Wikipedia,
The Free Encyclopedia, 2024 [visited o n 2024-12-05]. Available from:
h t t p s : //en. wi k i pedi a .org/w/i ndex. php? t i tle=Request°oE2°o80°o93respo
nse&oldid=1253546792.
109
BIBLIOGRAPHY
65. BURNS, Brendan. The Distributed System ToolKit: Patterns for Composite
Containers [online]. 2015-06-29. [visited on 2024-10-28]. Available from:
h t t p s : / / k u b e r n e t e s . i o / b l o g / 2 0 1 5 / 0 6 / t h e - d i s t r i b u t e d - s y s t e m - t o o l k i
t - p a t t e r n s / .
66. RICHARDSON, Chris. Pattern: Sidecar [online]. 2024. [visited on
2024-10-23]. Available from: https : / / m i c r o s e r v i c e s . i o / p a t t e r n s / d
eployment/sidecar.html. Page under construction.
67. MICROSOFT. Sidecar pattern [online]. 2022-07-28. [visited on
2024-10-23]. C l o u d Design Patterns. Available from: https : / / l e a r n
.mi crosoft.com/en-us/azu r e / a r c h i t e c t u r e / p a t t e r n s / s i d e c a r .
68. MICROSOFT. Ambassador pattern [online]. 2022-07-28. [visited on
2024-10-29]. Cloud Design Patterns. Available from: https://learn.mi
crosoft.com/en-us/azu r e / a r c h i t e c t u r e / p a t t e r n s / a m b a s s a d o r .
69. HOHPE, Gregor; WOOLF, Bobby. Channel Adapter [online]. 2003. [visited
on 2024-12-05]. Available from: https://www.enterprise!'ntegrati
onpatterns.com/patterns/messaging/ChannelAdapter.html.
70. THOMAS, David; HUNT, Andrew. The Pragmatic Programmer: Your
journey to mastery, 20th Anniversary Edition. Pearson Education, 2019.
ISBN 978-0-13-595705-9.
71. CALC,ADO, P h i l . The Back-end for Front-end Pattern (BFF) [online].
2015-09-18. [visited on 2024-10-23]. Available from: h t t p s : / / p h i I c a l c a
do.com/2015/09/18/the_back_end_for_front_end_pattern_bff.html.
72. NEWMAN, Sam. Backends ForFrontends [online]. 2015-11-18. [visited
on 2024-03-06]. Available from: https://samnewman.io/patterns/archi
t e c t u r a l / b f f / .
73- MICROSOFT. Backends for Frontends pattern [online]. 2022-07-28. [visited
on 2024-10-23]. Cloud Design Patterns. Available from: h t t p s : / / I
e a r n . m i c r o s o f t . c o m / e n - u s / a z u r e / a r c h i t e c t u r e / p a t t e r n s / b a c k e n d s - f o
r-frontends.
74- MICROSOFT. Pipes and Filters pattern [online]. 2024-04-10. [visited on
2024-10-29]. Cloud Design Patterns. Available from: https://learn.mi
c r o s o f t . c o m / e n - u s / a z u r e / a r c h i t e c t u r e / p a t t e r n s / p i p e s - a n d - f i l t e r s .
75- MICROSOFT. Geodes pattern [online]. 2024-03-18. [visited on
2024-10-29]. C l o u d Design Patterns. Available from: https : / / l e a r n
.microsoft.com/en-us/azure/architecture/patterns/geodes .
110
BIBLIOGRAPHY
76. HOHPE, Gregor; WOOLF, Bobby. Competing Consumers [online]. 2003.
[visited on 2024-10-23]. Available from: https://www.enterpriseintegr
ationpatterns.com/patterns/messaging/CompetingConsumers.html.
77. MICROSOFT. Competing Consumers pattern [online]. 2022-07-28. [visited
on 2024-10-29]. Cloud Design Patterns. Available from: h t t p s : / / I
earn.mi crosoft.com/en-us/azu r e / a r c h i t e c t u r e / p a t t e r n s / c o m p e t i n g - c
onsumers.
78. HOHPE, Gregor. Load Balancer [online]. 2017-01. [visited o n
2024-12-05]. Available from: h t t p s : / /www . enterprise!'ntegrationpa
tterns.com/patterns/conversation/LoadBalancer.html.
79- MICROSOFT. Sharding pattern [online]. 2022-07-28. [visited o n
2024-10-29]. C l o u d Design Patterns. Available from: https : / / l e a r n
. m i c r o s o f t . c o m / e n - u s / a z u r e / a r c h i t e c t u r e / p a t t e r n s / s h a r d i n g .
80. MICROSOFT. Sequential Convoy pattern [online]. 2019-12-14. [visited on
2024-11-16]. Cloud Design Patterns. Available from: https://learn.mi
c r o s o f t . c o m / e n - u s / a z u r e / a r c h i t e c t u r e / p a t t e r n s / s e q u e n t i a l - c o n v o y .
81. WIKIPEDIACONTRIBUTORS. Shard (database architecture) [online].
Wikipedia, The Free Encyclopedia, 2024 [visited on 2024-12-16]. Available
from: h t t p s : / / e n . w i k i p e d i a . o r g / w / i n d e x . p h p ? t i t l e = S h a r d _ ( d a t a
base_architecture)&oldid=i260915144.
82. WIKIPEDIA CONTRIBUTORS. Data striping [online]. Wikipedia, The
Free Encyclopedia, 2024 [visited on 2024-12-16]. Available from: https
://en.wikipedi a.org/w/i ndex.php?ti t l e = D a t a _ s t r i pi ng&oldi d=125527
6345.
83. MICROSOFT. Deployment Stamps pattern [online]. 2023-12-13. [visited
on 2024-10-29]. Cloud Design Patterns. Available from: h t t p s : / / l e a r n
.microsoft.com/en-us/azure/architecture/patterns/deployment-stam
P-
84. HOHPE, Gregor; WOOLF, Bobby. Scatter-Gather [online]. 2003. [visited
on 2024-11-02]. Available from: https://www.enterprise!'ntegrati
onpatterns.com/patterns/messaging/BroadcastAggregate.html.
85. DEENADAYALAN, A n i t h a . Scatter-gatherpattern [online]. A m a z o n
Web Services, 2024-05-07 [visited o n 2024-10-29]. C l o u d design patterns,
architectures, and implementations. Available from: https ://d
o c s . a w s . a m a z o n . c o m / p r e s c r i p t i v e - g u i d a n c e / l a t e s t / c l o u d - d e s i g n - p a t
t e r n s / s c a t t e r - g a t h e r . h t m l .
111
BIBLIOGRAPHY
86. WIKIPEDIA CONTRIBUTORS. Embarrassingly parallel [online]. Wikipedia,
The Free Encyclopedia, 2024 [visited on 2024-11-16]. Available
from: h t t p s : / / e n . w i k i p e d i a . o r g / w / i n d e x . p h p ? t i tle=Embarrassingly_p
arallel&oldid=_25_75434i.
87. RICHARDSON, Chris. Pattern: Externalized configuration [online].
2024. [visited o n 2024-10-30]. Available from: https : / / m i c r o s e r v i c
e s . i o / p a t t e r n s / e x t e r n a l i z e d - c o n f i g u r a t i o n . h t m l .
88. FEHLING, Christoph et al. Managed Configuration [online]. 2020. [visited
on 2024-11-17]. Available from: https://www.cloudcomputingpatter
ns.org/managed_configuration/.
89. MICROSOFT. External Configuration Store pattern [online]. 2021-09-14[visited
on 2024-10-29]. Cloud Design Patterns. Available from: https:
//learn.mi c r o s o f t . c o m / e n - u s / a z u r e / a r c h i t e c t u r e / p a t t e r n s / e x t e r n a l c
o n f i g u r a t i o n - s t o r e .
90. HOHPE, Gregor; WOOLF, Bobby. Control Bus [online]. 2003. [visited
o n 2024-11-13]. Available from: https://www.enterpriseintegrationpa
tterns.com/patterns/messaging/ControlBus.html.
91. MICROSOFT. Edge Workload Configuration pattern [online]. 2022-10-12.
[visited on 2024-10-29]. Cloud Design Patterns. Available from: https:
/ / l e a r n . m i c r o s o f t . c o m / e n - u s / a z u r e / a r c h i t e c t u r e / p a t t e r n s / e d g e - w o r
k l o a d - c o n f i g u r a t i o n .
92. MICROSOFT. Cloud design patterns that support reliability [online].
2024-10-10. [visited on 2024-12-15]. Azure Well-Architected Framework.
Available from: h t t p s : / / l e a r n . m i c r o s o f t . c o m / e n - u s / a z u r e / w e l l - a r c h i
t e c t e d / r e l i a b i l i t y / d e s i g n - p a t t e r n s .
93- MICROSOFT. Cache-Aside pattern [online]. 2022-07-28. [visited o n
2024-10-26]. C l o u d Design Patterns. Available from: h t t p s : / / l e a r n
. m i c r o s o f t . c o m / e n - u s / a z u r e / a r c h i t e c t u r e / p a t t e r n s / c a c h e - a s i d e .
94- MICROSOFT. Throttling pattern [online]. 2022-07-28. [visited o n
2024-10-29]. C l o u d Design Patterns. Available from: https : / / l e a r n
. m i c r o s o f t . c o m / e n - u s / a z u r e / a r c h i t e c t u r e / p a t t e r n s / t h r o t t l i n g .
95. MICROSOFT. Compensating Transaction pattern [online]. 2022-07-28.
[visited on 2024-10-29]. Cloud Design Patterns. Available from: https:
/ / l e a r n . m i c r o s o f t . c o m / e n - u s / a z u r e / a r c h i t e c t u r e / p a t t e r n s / c o m p e n s a
t i n g - t r a n s a c t i o n .
112
BIBLIOGRAPHY
96. MICROSOFT. Bulkhead pattern [online]. 2022-07-28. [visited on
2024-10-26]. C l o u d Design Patterns. Available f r o m : h t t p s : / / l e a r n
. m i c r o s o f t . c o m / e n - u s / a z u r e / a r c h i t e c t u r e / p a t t e r n s / b u l k h e a d.
97. WIKIPEDIA CONTRIBUTORS. Bulkhead (partition) [online]. W i k i pedia,
The Free Encyclopedia, 2024 [visited on 2024-11-17]. Available
from: h t t p s : / / e n . w i k i p e d i a . o r g / w / i n d e x . p h p ? t i t l e = B u l k h e a d _ ( p a r t i
tion)&oldid=1255984059.
98. WIKIPEDIA CONTRIBUTORS. Threadpool [online]. Wikipedia, The
Free Encyclopedia, 2023 [visited on 2024-11-17]. Available from: https:
//en.wi k i pedi a.org/w/i ndex.php?ti tle=Th r e a d _ p o o l & o l d i d=113882927
5.
99- MICROSOFT. Queue-Based Load Leveling pattern [online]. 2022-07-28.
[visited on 2024-10-29]. Cloud Design Patterns. Available from: https:
/ / l e a r n . m i c r o s o f t . c o m / e n - u s / a z u r e / a r c h i t e c t u r e / p a t t e r n s / q u e u e - b a
s e d - l o a d - l e v e l i n g .
100. HOHPE, Gregor; WOOLF, Bobby. Point-to-PointChannel [online]. 2003.
[visited on 2024-12-02]. Available from: https://www.enterpriseintegr
ationpatterns.com/patterns/messagi ng/Poi ntToPoi ntChannel.html.
101. MICROSOFT. Retry pattern [online]. 2022-07-18. [visited on
2024-10-26]. Cloud Design Patterns. Available from: https://learn.mi
c r o s o f t . c o m / e n - u s / a z u r e / a r c h i t e c t u r e / p a t t e r n s / r e t r y .
102. DEENADAYALAN, Anitha. Retry with backoffpattern [online]. Amazon
Web Services, 2023-07-28 [visited o n 2024-10-26]. Cloud design patterns,
architectures, and implementations. Available from: https ://d
o c s . a w s . a m a z o n . c o m / p r e s c r i p t i v e - g u i d a n c e / l a t e s t / c l o u d - d e s i g n - p a t
t e r n s / r e t r y - b a c k o f f . h t m l .
103. HOHPE, Gregor. Request-Response with Retry [online]. 2017-01. [visited
on 2024-12-05]. Available from: https://www.enterpriseintegrationpa
tterns.com/patterns/conversation/RequestResponseRetry.html.
104. FEHLING, Christoph et al. At-least-onceDelivery [online]. 2020. [visited
on 2024-10-26]. Available f r o m : https://www.cloudcomputingpatterns
. o r g / a t _ l e a s t _ o n c e _ d e l i v e r y / .
105. WIKIPEDIA CONTRIBUTORS. Exponential backoff [online]. Wikipedia,
The Free Encyclopedia, 2024 [visited o n 2024-11-18]. Available
from: https://en.wi k i pedi a.org/w/i ndex.php?ti tle=Exponenti al_back
offSoldid=1244695962.
113
BIBLIOGRAPHY
106. BROOKER, Marc. Exponential Backoff And Jitter [online]. A m a z o n Web
Services, 2015-03-04 [visited on 2024-11-18]. Available from: https://a
w s . a m a z o n . c o m / b l o g s / a r c h i t e c t u r e / e x p o n e n t i a l - b a c k o f f - a n d - j i t t e r / .
107. WIKIPEDIA CONTRIBUTORS. Thundering herdproblem [online]. Wikipedia,
The Free Encyclopedia, 2023 [visited on 2024-11-18]. Available
from: h t t p s : //en.wi k i p e d i a . o r g / w / i n d e x . p h p ? t i tle=Thunderi ng_herd
_problem&oldid=1177436868.
108. MICROSOFT. Health Endpoint Monitoring pattern [online]. 2022-07-28.
[visited on 2024-10-29]. Cloud Design Patterns. Available from: https:
/ / l e a r n . m i crosoft.com/en-us/azu r e / a r c h i t e c t u r e / p a t t e r n s / h e a l t h - e
ndpoint-monitoring.
109. FEHLING, Christoph et al. Watchdog [online]. 2020. [visited on
2024-11-06]. Available from: https://www.cloudcomputingpatterns.org
/watchdog/.
110. RICHARDSON, Chris. Pattern: Health Check API [online]. 2024. [visited
on 2024-11-06]. Available from: h t t p s : / / m i c r o s e r v i c e s . i o / p a t t e r n s / o
b s e r v a b i l i t y / h e a l t h - c h e c k - a p i . h t m l .
111. JOSHI, Unmesh. HeartBeat [online]. Martin Fowler, 2023-11-23 [visited
on 2024-12-11]. Catalog of Patterns of Distributed Systems. Available
from: h t t p s : / / m a r t i n f o w l e r . c o m / a r t i c l e s / p a t t e r n s - o f - d i s t r i b u t e d - s
ystems/heartbeat.html.
112. HOHPE, Gregor; WOOLF, Bobby. Control Bus [online]. 2003. [visited
on 2024-12-11]. Available from: https://www.enterpriseintegrationpa
tterns.com/patterns/messaging/ControlBus.html.
113. HOHPE, Gregor; WOOLF, Bobby. Test Message [online]. 2003. [visited
on 2024-12-11]. Available from: https://www.enterpriseintegrationpa
tterns.com/patterns/messaging/TestMessage.html.
114. MICROSOFT. Rate Limiting pattern [online]. 2022-07-28. [visited on
2024-10-29]. Cloud Design Patterns. Available from: https://learn.mi
c r o s o f t . c o m / e n - u s / a z u r e / a r c h i t e c t u r e / p a t t e r n s / r a t e - l i m i t i n g - p a t t
ern.
115. WIKIPEDIA CONTRIBUTORS. Denial-of-service attack [online]. Wikipedia,
The Free Encyclopedia, 2024 [visited on 2024-11-20]. Available
from: h t t p s : / / e n . w i k i p e d i a . o r g / w / i n d e x . p h p ? t i t l e = D e n i a l - o f - s e r v i
ce_attack&oldid=1258567977.
114
BIBLIOGRAPHY
116. MAHDI, Nikrad. An alternative approach to rate limiting [online]. Figma
Design, 2017-04-12 [visited on 2024-11-20]. Available from: https://me
d i u m . c o m / f i g m a - d e s i g n / a n - a l t e r n a t i v e - a p p r o a c h - t o - r a t e - l i m i t i n g - f
8a06cf7c94c.
117. NOORMOHAMMADPOUR, Max; RAGHAVENDRA, Cauligi. Datacenter
Traffic Control: Understanding Techniques and Trade-offs. IEEE
Communications Surveys & Tutorials. 2018, vol. 20, pp. 1492-1525. Available
from DOl: 10.1109/COMST. 2017.2782753.
118. WIKIPEDIA CONTRIBUTORS. Rate limiting [online]. Wikipedia, The
Free Encyclopedia, 2024 [visited on 2024-11-20]. Available from: https
: / / e n . w i k i p e d i a . o r g / w / i n d e x . p h p ? t i t l e = R a t e _ l i m i t i n g & o l d i d = 1 2 3 9 7 8
2071.
119. JO SHI, U n m e s h . Leader and Followers [online]. M a r t i n Fowler,
2023-11-23 [visited on 2024-11-03]. Catalog of Patterns of Distributed
Systems. Available from: h t t p s : / / m a r t i n f o w l e r . c o m / a r t i c l e s / p a t t e r n
s - o f - d i s t r i b u t e d - s y s t e m s / l e a d e r - f o l l o w e r . h t m l .
120. MICROSOFT. Leader Election pattern [online]. 2024-05-30. [visited on
2024-10-29]. Cloud Design Patterns. Available from: https://learn.mi
c r o s o f t . c o m / e n - u s / a z u r e / a r c h i t e c t u r e / p a t t e r n s / l e a d e r - e l e c t i o n .
121. REED, Benjamin; JUNQUEIRA, Flavio P. A simple totally ordered
broadcast protocol. In: Proceedings of the 2nd Workshop on Large-Scale
Distributed Systems and Middleware. Yorktown Heights, N e w York,
USA: Association for Computing Machinery, 2008. LADIS '08. ISBN
9781605582962. Available from DOl: 10.1145/1529974.1529978.
122. ONGARO, Diego; OUSTERHOUT, John. In search of an understandable
consensus algorithm. In: Proceedings of the 2014 USENIX Conference
on USENIX Annual Technical Conference. Philadelphia, PA: USENIX
Association, 2014, pp. 305-320. USENIX ATC'14. ISBN9781931971102.
123. WIKIPEDIA CONTRIBUTORS. Leader election [online]. W i k i p e d i a ,
The Free Encyclopedia, 2024 [visited on 2024-12-04]. Available from:
h t t p s : / / e n . w i k i p e d i a.org/w/i ndex.php?ti t l e = L e a d e r _ e l e c t i on&oldi d
=1258669283.
124. MICROSOFT. Cloud design patterns that support performance efficiency
[online]. 2024-10-10. [visited on 2024-12-15]. Azure Well-Architected
Framework. Available from: https://learn.microsoft.com/en-us/azur
e / w e U - a r c h i t e c t e d / p e r f o r m a n c e - e f f i c i e n c y / d e s i g n - p a t t e r n s .
115
BIBLIOGRAPHY
125. MICROSOFT. Index Table pattern [online]. 2022-07-28. [visited o n
2024-10-29]. C l o u d Design Patterns. Available from: https : / / l e a r n
. m i c r o s o f t . c o m / e n - u s / a z u r e / a r c h i t e c t u r e / p a t t e r n s / i n d e x - t a b l e .
126. MICROSOFT. Materialized View pattern [online]. 2022-07-28. [visited
on 2024-10-29]. Cloud Design Patterns. Available from: h t t p s : / / l e a r n
. m i c r o s o f t . c o m / e n - u s / a z u r e / a r c h i t e c t u r e / p a t t e r n s / m a t e r i a l i z e d - v i
ew.
127. MICROSOFT. Compute Resource Consolidation pattern [online].
2022-07-28. [visited on 2024-10-29]. Cloud Design Patterns. Available
from: h t t p s : / / l e a r n . m i c r o s o f t . c o m / e n - u s / a z u r e / a r c h i t e c t u r e / p a t t e r
ns/compute-resource-consolidation.
128. MICROSOFT. Static Content Hosting pattern [online]. 2022-07-28. [visited
on 2024-10-29]. Cloud Design Patterns. Available from: h t t p s : / / I
e a r n . m i c r o s o f t . c o m / e n - u s / a z u r e / a r c h i t e c t u r e / p a t t e r n s / s t a t i c - c o n t
ent-hosting.
129. MICROSOFT. Valet Key pattern [online]. 2024-05-08. [visited o n
2024-10-29]. C l o u d Design Patterns. Available from: https : / / l e a r n
. m i c r o s o f t . c o m / e n - u s / a z u r e / a r c h i t e c t u r e / p a t t e r n s / v a l e t - k e y.
130. RICHARDSON, Chris. Pattern: Circuit Breaker [online]. 2024. [visited
on 2024-10-30]. Available from: h t t p s : / / m i c r o s e r v i c e s . i o / p a t t e r n s / r
e l i a b i l i t y / c i r c u i t - b r e a k e r . h t m l .
131. MICROSOFT. Circuit Breaker pattern [online]. 2022-07-28. [visited on
2024-10-29]. Cloud Design Patterns. Available from: https://learn.mi
c r o s o f t . c o m / e n - u s / a z u r e / a r c h i t e c t u r e / p a t t e r n s / c i r c u i t - b r e a k e r .
132. DEENADAYALAN, A n i t h a . Circuit breaker pattern [online]. A m a z o n
Web Services, 2023-07-28 [visited o n 2024-10-26]. C l o u d design patterns,
architectures, and implementations. Available from: https ://d
ocs.aws.amazon.com/prescriptive-guidance/latest/cloud-design-pat
t e r n s / c i r c u i t - b r e a k e r . h t m l .
133. WIKIPEDIA CONTRIBUTORS. Circuit breaker [online]. W i k i p e d i a ,
The Free Encyclopedia, 2024 [visited o n 2024-11-19]. Available from:
https://en.wi k i p e d i a.org/w/i ndex.php?ti t l e = C i rcui t _ b r e a k e r & o l d i d
=1252964096.
134. DIEULOT, Alexandre, instant.page [online]. 2023-03-21. [visited o n
2024-12-12]. Available from: https://instant.page/ .
116
BIBLIOGRAPHY
135- WIKIPEDIACONTRIBUTORS. Circuit breaker design pattern [online].
Wikipedia, The Free Encyclopedia, 2024 [visited on 2024-12-16]. Available
from: https://en.wikipedia.org/w/index.php?title=Ci r c u i t _ b r e
aker_design_pattern&oldid=i263311775.
136. FOWLER, M a r t i n . Remote Facade [online]. 2003-03-05. [visited on
2024-11-22]. Available from: https : / / m a r t i n f o w l e r . com/eaaCatalog
/remoteFacade.html.
137. HOHPE, Gregor; WOOLF, Bobby. Claim Check [online]. 2003. [visited
on 2024-10-20]. Available from: https://www.enterpriseintegrationpa
t t e r n s . c o m / p a t t e r n s / m e s s a g i n g / S t o r e l n L i b r a r y . h t m l .
138. MICROSOFT. Claim-Check pattern [online]. 2024-05-01. [visited on
2024-10-29]. Cloud Design Patterns. Available from: https://learn.mi
c r o s o f t . c o m / e n - u s / a z u r e / a r c h i t e c t u r e / p a t t e r n s / c l a i m - c h e c k.
139. RICHARDSON, Chris. Pattern: Command Query Responsibility Segregation
(CQRS) [online]. 2024. [visited on 2024-10-30]. Available from:
h t t p s : / / m i c r o s e r v i c e s . i o / p a t t e r n s / d a t a / c q r s . h t m l .
140. MICROSOFT. CQRS pattern [online]. 2022-07-28. [visited on
2024-10-29]. Cloud Design Patterns. Available from: https://learn.mi
c r o s o f t . c o m / e n - u s / a z u r e / a r c h i t e c t u r e / p a t t e r n s / c q r s .
141. DAHAN, U d i . Clarified CQRS [online]. 2009-12-09. [visited on
2024-10-28]. Available from: https : / /udidahan . c o m / 2 0 0 9 / 1 2 / 0 9 / c l
a r i f i e d - c q r s / .
142. YOUNG, Greg. CQRS Documents [online]. 2010-10. [visited on
2024-10-28]. Available from: https : / / c q r s . wordpress . com/wp-cont
ent/uploads/2010/ll/cqrs_documents.pdf.
143. FOWLER, M a r t i n . CQRS [online]. 2011-07-14. [visited on 2024-03-01].
Available from: https://martinfowler.com/bliki/CQRS.html.
144. WIKIPEDIA CONTRIBUTORS. Command Query Responsibility Segregation
[online]. W i k i p e d i a , The Free Encyclopedia, 2024 [visited on
2024-11-28]. Available from: https://en. wi k i pedi a .org/w/i ndex. php?t
i tle=Command_Query_Responsi b i l i t y _ S e g r e g a t i on&oldi d=1251978026.
145. FOWLER, Martin. Reporting Database [online]. 2014-04-02. [visited on
2024-11-28]. Available from: h t t p s : / / m a r t i n f o w l e r . c o m / b l i k i / R e p o r t i
ngDatabase.html.
146. RICHARDSON, Chris. Pattern: Command-side replica [online]. 2024.
[visited on 2024-10-30]. Available from: h t t p s : / / m i c r o s e r v i c e s . i o / p a t
terns/data/command-side-replica, html.
117
BIBLIOGRAPHY
147. FERNANDEZ-BUGLIONI, Eduardo. Security Patterns in Practice:
Designing Secure Architectures Using Software Patterns. Wiley, 2013.
W i l e y Software Patterns Series, ISBN 9781119970484. Available also
from: https://books.google.cz/books?id=3vppszXPdrOC.
148. MICROSOFT. Cloud design patterns that support security [online].
2024-10-10. [visited o n 2024-12-15]. Azure Well-Architected Framework.
Available from: https://learn.microsoft.com/en-us/azure/well
- a r c h i t e c t e d / s e c u r i t y / d e s i g n - p a t t e r n s .
149. MICROSOFT. Quarantine pattern [online]. 2024-01-19. [visited on
2024-12-15]. Cloud Design Patterns. Available from: https : / / l e a r n
. m i c r o s o f t . c o m / e n - u s / a z u r e / a r c h i t e c t u r e / p a t t e r n s / q u a r a n t i n e .
150. DELESSY, Nelly; FERNANDEZ, Eduardo B; LARRONDO-PETRIE,
M a r i a M . A pattern language for identity management. In: 2007 International
Multi-Conference on Computing in the Global Information
Technology (ICCGI'07). IEEE, 2007, pp. 31-31.
151. MICROSOFT. Federated Identity Pattern [online]. 2022-07-28. [visited
on 2024-10-29]. Cloud Design Patterns. Available from: h t t p s : / / l e a r n
. m i c r o s o f t . c o m / e n - u s / a z u r e / a r c h i t e c t u r e / p a t t e r n s / f e d e r a t e d - i d e n t
i t y .
152. RICHARDSON, Chris. Pattern: Access token [online]. 2024. [visited on
2024-10-30]. Available from: h t t p s : / / m i c r o s e r v i c e s . i o / p a t t e r n s / s e c u
r i ty/access-token.html.
153. AL-SLAIS, Yaqoob; EL-MEDANY, Wael M . User-centric adaptive password
policies to combat password fatigue. Int. Arab J. Inf. Technol. 2022,
vol. 19, no. 1, pp. 55-62.
154. KORBAR, Bruno et al. Validating an agent-based m o d e l of h u m a n
password behavior. In: Workshops at the Thirtieth AAA! Conference on
Artificial Intelligence. 2016.
155. WIKIPEDIA CONTRIBUTORS. Password fatigue [online]. Wikipedia,
The Free Encyclopedia, 2024 [visited on 2024-11-30]. Available from:
https://en.wi k i pedi a.org/w/i ndex.php?ti t l e = P a s s w o r d _ f a t i gue&oldi
d=1251069983.
156. HARDY, N o r m . The Confused Deputy: (or why capabilities might have
been invented). SIGOPS Oper. Syst. Rev. [online]. 1988, vol. 22, no. 4,
pp. 36-38 [visited on 2024-11-09]. ISSN 0163-5980. Available from DOI:
10.1145/54289.871709.
118
BIBLIOGRAPHY
157. W i K i P E D i A CONTRIBUTORS. Confused deputy problem [online]. Wikipedia,
The Free Encyclopedia, 2024 [visited on 2024-11-09]. Available
from: https://en.wikipedia.org/w/index.php?title=Confused_deputy
_problem&oldid=1230222963.
158. W i K i P E D i A CONTRIBUTORS. Identity provider [online]. Wikipedia,
The Free Encyclopedia, 2024 [visited o n 2024-11-29]. Available from:
https://en.wi k i pedi a.org/w/i ndex.php?ti t l e = I d e n t i ty_provi der&old
id=1255298094.
159. WIKIPEDIACONTRIBUTORS. Federated identity [online]. Wikipedia,
The Free Encyclopedia, 2024 [visited o n 2024-11-29]. Available from:
h t t p s : / / e n . w i k i p e d i a . o r g / w / i n d e x . p h p ? t i t l e = F e d e r a t e d . i d e n t i t y & o l
did=1250064587.
160. MICROSOFT. Gatekeeper pattern [online]. 2023-05-26. [visited o n
2024-10-29]. C l o u d Design Patterns. Available from: https : / / l e a r n
.microsoft.com/en-us/azure/architecture/patterns/gatekeeper.
161. KIRSTENS ET AL. Cross Site Scripting (XSS) [online]. OWASP Foundation,
2024 [visited o n 2024-12-13]. Available from: https://owasp.org
/www-communi t y / a t t a c k s / x s s / .
162. WIKIPEDIA CONTRIBUTORS. Honeypot (computing) [online]. W i k i pedia,
The Free Encyclopedia, 2024 [visited on 2024-12-13]. Available
from: https://en.wi k i pedi a.org/w/i ndex.php?ti tle=Honeypot_(compu
ting)&oldid=1256232168.
163. FEHLING, Christoph et al. Transaction-based Processor [online]. 2020.
[visited on 2024-11-17]. Available from: https://www.cloudcomputingpa
t t e r n s . o r g / t r a n s a c t i o n _ b a s e d _ p r o c e s s o r / .
164. HOHPE, Gregor; WOOLF, Bobby. Transactional Client [online]. 2003.
[visited on 2024-12-04]. Available from: https://www.enterpriseintegr
a t i o n p a t t e r n s . c o m / p a t t e r n s / m e s s a g i n g / T r a n s a c t i o n a l C l i e n t . h t m l .
165. RICHARDSON, Chris. Pattern: Transactional outbox [online]. 2024.
[visited on 2024-10-30]. Available from: h t t p s : / / m i c r o s e r v i c e s . i o / p a t
t e r n s / d a t a / t r a n s a c t i o n a l - o u t b o x . h t m l .
166. DEENADAYALAN, A n i t h a . Transactional outbox pattern [online].
A m a z o n Web Services, 2023-07-28 [visited o n 2024-10-29]. C l o u d
design patterns, architectures, and implementations. Available from:
https://docs.aws.amazon.com/prescriptive-guidance/latest/cloud-d
e s i g n - p a t t e r n s / t r a n s a c t i o n a l - o u t b o x . h t m l .
119
BIBLIOGRAPHY
167. JO SHI, U n m e s h . Two-Phase Commit [online]. M a r t i n Fowler,
2023- 11-23 [visited o n 2024-11-30]. Catalog of Patterns of Distributed
Systems. Available from: h t t p s : / / m a r t i n f o w l e r . c o m / a r t i c l e s / p a t t e r n
s - o f - d i s t r i buted-systems/two-phase-commi t.html.
168. WIKIPEDIA CONTRIBUTORS. Two-phase commit protocol [online].
Wikipedia, The Free Encyclopedia, 2024 [visited on 2024-11-30]. Available
from: https://en.wikipedia.org/w/index.php?title=Two-phase_c
ommit_protocol&oldid=1259467470.
169. HELLAND, Pat. Life Beyond Distributed Transactions: A n apostate's
opinion. Queue. 2016, vol. 14, no. 5, pp. 69-98. ISSN 1542-7730. Available
from DOl: 10.1145/3012426.3025012.
170. RICHARDSON, Chris. Pattern: Polling publisher [online]. 2024. [visited
on 2024-10-30]. Available from: h t t p s : / / m i c r o s e r v i c e s . i o / p a t t e r n s / d
a t a / p o l l i n g - p u b l i s h e r . h t m l .
171. RICHARDSON, Chris. Pattern: Transaction log tailing [online]. 2024.
[visited on 2024-10-30]. Available from: h t t p s : / / m i c r o s e r v i c e s . i o / p a t
t e r n s / d a t a / t r a n s a c t i o n - l o g - t a i l i n g . h t m l .
172. GARCIA-MOLINA, Hector; SALEM, Kenneth. Sagas. SIGMOD Rec.
1987, vol. 16, no. 3, pp. 249-259. ISSN 0163-5808. Available from DOI:
10.1145/38714.38742.
173. RICHARDSON, Chris. Pattern: Saga [online]. 2024. [visited o n
2024-10-30]. Available from: https : / / m i c r o s e r v i c e s . i o / p a t t e r n s / d
ata/saga.html.
174. MICROSOFT. Sagapattern [online]. 2022-07-28. [visited on 2024-10-29].
Cloud Design Patterns. Available from: https://learn.microsoft.com
/ e n - u s / a z u r e / a r c h i t e c t u r e / r e f e r e n c e - a r c h i t e c t u r e s / s a g a / s a g a .
175. DEENADAYALAN, A n i t h a . Saga patterns [online]. A m a z o n Web Services,
2023-07-28 [visited on 2024-10-29]. Cloud design patterns, architectures,
and implementations. Available from: https://docs.aws.am
a z o n . c o m / p r e s c r i p t i v e - g u i d a n c e / l a t e s t / c l o u d - d e s i g n - p a t t e r n s / s a g a
.html.
176. GARCIA-MOLINA, Hector et al. M o d e l i n g long-running activities as
nested sagas. Data Eng. 1991, vol. 14, no. 1, pp. 14-18.
177. RICHARDSON, Chris. Using sagas to maintain data consistency in
a microservice architecture [online]. Devoxx, 2017-05-17 [visited o n
2024-12-01]. Available from: h t t p s : //youtu. be/YPbGW3Fnmbc.
120
BIBLIOGRAPHY
178. FRIEDRICHSEN, Uwe. The limits of the Saga pattern [online].
2021-02-19. [visited o n 2024-11-30]. Available from: https : / /www. u
f r i e d . c o m / b l o g / l i m i t s _ o f _ s a g a _ p a t t e r n / .
179. WIKIPEDIA CONTRIBUTORS. Long-running transaction [online].
Wikipedia, The Free Encyclopedia, 2024 [visited on 2024-12-02]. Available
from: https://en.wikipedia.org/w/index. php?title=Long-runnin
g_transaction&oldid=i2_208923i.
180. WIKIPEDIA CONTRIBUTORS. Compensating transaction [online].
Wikipedia, The Free Encyclopedia, 2024 [visited on 2024-12-02]. Available
from: h t t p s : //en. wi k i pedi a .org/w/i ndex. php?ti tle=Compensati n
g_transaction&oldid=12275042_9.
181. DEENADAYALAN, A n i t h a . AWS Choreography Pattern [online].
Amazon Web Services, 2023-10-14 [visited on 2024-10-29]. Cloud design
patterns, architectures, and implementations. Available from: https:
//aws.amazon.com/documentati on/choreography.
182. DEENADAYALAN, Anitha. Saga orchestration pattern [online]. Amazon
Web Services, 2023-07-28 [visited o n 2024-10-29]. C l o u d design patterns,
architectures, and implementations. Available from: https ://d
ocs.aws.amazon.com/prescriptive-guidance/latest/cloud-design-pat
t e r n s / s a g a - o r c h e s t r a t i o n . h t m l .
183. MICROSOFT. Scheduler Agent Supervisor pattern [online]. 2022-07-28.
[visited on 2024-12-02]. Cloud Design Patterns. Available from: https:
/ / l e a r n . m i crosoft.com/en-us/azu r e / a r c h i t e c t u r e / p a t t e r n s / s c h e d u l e
r-agent-supervisor.
184. FOWLER, M a r t i n . Event Sourcing [online]. 2005-12-12. [visited on
2024-10-26]. Available from: https://martinfowler.com/eaaDev/Eve
ntSourcing.html.
185. RICHARDSON, Chris. Pattern: Event sourcing [online]. 2024. [visited
on 2024-10-26]. Available from: h t t p s : / / m i c r o s e r v i c e s . i o / p a t t e r n s / d
ata/event-sourcing.html.
186. MICROSOFT. Event Sourcing pattern [online]. 2022-07-28. [visited on
2024-10-26]. Cloud Design Patterns. Available from: https://learn.mi
c r o s o f t . c o m / e n - u s / a z u r e / a r c h i t e c t u r e / p a t t e r n s / e v e n t - s o u r c i n g .
121
BIBLIOGRAPHY
187. DEENADAYALAN, A n i t h a . Event sourcingpattern [online]. A m a z o n
Web Services, 2023-10-14 [visited on 2024-10-29]. Cloud design patterns,
architectures, and implementations. Available from: https://d
o c s . a w s . a m a z o n . c o m / p r e s c r i p t i v e - g u i d a n c e / l a t e s t / c l o u d - d e s i g n - p a t
t e r n s / e v e n t - s o u r c i n g . h t m l .
188. WIKIPEDIACONTRIBUTORS. Event-driven architecture [online]. Wikipedia,
The Free Encyclopedia, 2024 [visited on 2024-12-16]. Available
from: h t t p s : //en.wikipedia.org/w/index. p h p ? t i t l e = E v e n t - d r i v e n _ a r
chitecture&oldid=1262812523.
189. NEWMAN, Sam. Monolith to Microservices: Evolutionary Patterns to
Transform Your Monolith. O'Reilly Media, 2019. ISBN 978-1-492-07554-7.
190. EVANS, Eric. Domain-Driven Design: Tackling Complexity in the Heart of
Software. Addison-Wesley Professional, 2004. ISBN 978-0-321-12521-7.
191. RICHARDSON, Chris. Pattern: Anti-corruption layer [online]. 2024.
[visited on 2024-10-30]. Available from: h t t p s : / / m i c r o s e r v i c e s . i o / p a t
terns/api gateway .html. Page under construction.
192. DEENADAYALAN, Anitha. Anti-corruption layer pattern [online].
A m a z o n Web Services, 2023-07-28 [visited o n 2024-10-29]. Cloud
design patterns, architectures, and implementations. Available from:
h t t p s : / / d o c s . a w s . a m a z o n . c o m / p r e s c r i p t i v e - g u i d a n c e / l a t e s t / c l o u d - d
e s i g n - p a t t e r n s / a c l . h t m l .
193. MICROSOFT. Anti-corruption Layer pattern [online]. 2022-07-28. [visited
on 2024-10-28]. Cloud Design Patterns. Available from: h t t p s : / / I
e a r n . m i c r o s o f t . c o m / e n - u s / a z u r e / a r c h i t e c t u r e / p a t t e r n s / a n t i - c o r r u p
t i o n - l a y e r .
194. FOWLER, M a r t i n . Refactoring code that accesses external services [online].
2015-02-17. [visited on 2024-02-12]. Available from: https://mart
i n f o w l e r . c o m / a r t i c l e s / r e f a c t o r i n g - e x t e r n a l - s e r v i ce.html.
195. FOWLER, Martin. Gateway [online]. 2021-08-10. [visited on 2024-12-03].
Available from: h t t p s : / / m a r t i n f o w l e r . c o m / a r t i c l e s / g a t e w a y - p a t t e r n
.html.
196. WIKIPEDIA CONTRIBUTORS. Facade pattern [online]. Wikipedia,
The Free Encyclopedia, 2024 [visited on 2024-12-03]. Available from:
h t t p s : / / e n . w i k i p e d i a . o r g / w / i ndex.php?ti t l e = F a c a d e . p a t t e r n & o l d i d
=1250938293.
122
BIBLIOGRAPHY
197. WIKIPEDIA CONTRIBUTORS. Adapter pattern [online]. Wikipedia,
The Free Encyclopedia, 2024 [visited on 2024-12-03]. Available from:
h t t p s : / / e n . w i k i p e d i a.org/w/i ndex.php?ti t l e = A d a p t e r _ p a t t e r n & o l d i d
=1235788258.
198. WIKIPEDIA CONTRIBUTORS. Mediator pattern [online]. Wikipedia,
The Free Encyclopedia, 2024 [visited on 2024-12-03]. Available from:
https://en.wi k i pedi a.org/w/i ndex.php?ti tle=Medi a t o r _ p a t t e r n & o l d i
d=1234081821.
199. FOWLER, M a r t i n . Strangler Fig Application [online]. 2004-06-01. [visited
on 2024-12-03]. Available from: h t t p s : / / m a r t i n f o w l e r . c o m / b l i k i
/ O r i g i n a l S t r a n g l e r F i g A p p l i c a t i o n . h t m l .
200. FOWLER, M a r t i n . Strangler Fig [online]. 2024-08-22. [visited on
2024-10-28]. Available from: h t t p s : / / m a r t i n f o w l e r . c o m / b l i k i / S t r a
n g l e r F i g A p p l i c a t i o n . h t m l .
201. RICHARDSON, Chris. Pattern: Strangler application [online]. 2024. [visited
on 2024-10-30]. Available from: h t t p s : / / m i c r o s e r v i c e s . i o / p a t t e r
ns/communication-style/messaging.html.
202. DEENADAYALAN, Anitha. Strangler fig pattern [online]. A m a z o n Web
Services, 2023-07-28 [visited o n 2024-10-29]. C l o u d design patterns,
architectures, and implementations. Available from: https://docs.a
w s . a m a z o n . c o m / p r e s c r i p t i v e - g u i d a n c e / l a t e s t / c l o u d - d e s i g n - p a t t e r n s
/ s t r a n g l e r - f i g . h t m l .
203. MICROSOFT. Strangler Fig pattern [online]. 2022-07-28. [visited on
2024-10-29]. Cloud Design Patterns. Available from: https://learn.mi
c r o s o f t . c o m / e n - u s / a z u r e / a r c h i t e c t u r e / p a t t e r n s / s t r a n g l e r - f i g .
204. WIKIPEDIA CONTRIBUTORS. Strangler fig application [online]. Wikipedia,
The Free Encyclopedia, 2024 [visited on 2024-12-03]. Available
from: https://en.wi k i p e d i a . o r g / w / i n d e x . p h p ? t i t l e = S t r a n g l e r _ f i g & o
ldid=1250144779.
205. WIKIPEDIA CONTRIBUTORS. Big bang adoption [online]. Wikipedia,
The Free Encyclopedia, 2024 [visited on 2024-12-03]. Available from:
h t t p s : / / e n . w i k i p e d i a . o r g / w / i n d e x . p h p ? t i t l e = B i g _ b a n g _ a d o p t i o n & o l d
id=1230084412.
206. HOHPE, Gregor; W 0 0 L F , Bobby. Messaging Bridge [online]. 2003.
[visited on 2024-11-06]. Available from: https://www.enterpriseintegr
ationpatterns.com/patterns/messaging/MessagingBridge.html .
123
BIBLIOGRAPHY
207. MICROSOFT. Messaging Bridge pattern [online]. 2022-07-28. [visited on
2024-10-29]. Cloud Design Patterns. Available from: https://learn.mi
c r o s o f t . c o m / e n - u s / a z u r e / a r c h i t e c t u r e / p a t t e r n s / m e s s a g i n g - b r i d g e .
208. FEHLING, Christoph et al. Message Mover [online]. 2020. [visited on
2024-11-17]. Available from: https://www.cloudcomputingpatterns.org
/message_mover/.
124
A Digital attachments
• daap.zip - source code of the website
125