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 many others in chapters 6–11. It starts with two single-node patterns by Burns [22].
Sidecar in § 5.1 is a pattern that allows to offload cross-cutting concerns to a locally running component, such as a container or a process, in a programming language–agnostic way – which has since become a general term for any locally running supporting component
Similarly, Ambassador in § 5.2 is a pattern that allows to handle network communication on behalf of a service, thus allowing it to be extended with any functionality needed
It then continues with two common approaches to handle client-facing cross-cutting concerns:
Offload to Gateway in § 5.3 is a simple pattern that puts shared functionality into a gateway, which works well for smaller applications but does not scale
Backend for Frontend (BFF) in § 5.4 is a (more costly) solution that overcomes this issue and has been shown to work well in practice
In a sense, other patterns could also be considered a part of this category:
Bulkheads define general principles on how to decompose, structure or isolate a system
Identity Provider and Externalised Configuration both extract functionality into common services
Gatekeeper forces decomposition to isolate security incidents and Aggregating Gateway to improve performance of unreliable clients
Anti-Corruption Layer extracts functionality to preserve semantics between different systems
Messaging Bridge is a shareable component used for connecting two services with incompatible messaging middleware
Notable omissions in this category due to the methodology described in § 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, in contrast to the other two. In a sense, it can be seen as a sidecar anti-corruption layer and is presented in this work as such in § 11.1
The Service Mesh pattern by Richardson [20, p. 380], a concept mostly used in the context of microservices