-
Notifications
You must be signed in to change notification settings - Fork 66
Evolutions of a Proxy
It usually makes little sense to get rid of a Proxy once it is integrated into the system. Its only real drawback is a slight increase in latency for user requests which may be helped through creation of bypass channels between the clients and a service which needs low latency. The other drawback of the pattern, namely the Proxy’s being a single point of failure, is countered by deploying multiple instances of the Proxy.
As Proxies are usually third-party products, there is very little we can change about them:
- We can add another kind of a Proxy on top of the existing one.
- We can use a stack of Proxies per client, making Backends for Frontends.
Goal: avoid implementing generic functionality.
Prerequisite: you don't have this kind of Proxy yet.
A system is not limited to a single kind of Proxies. As a Proxy represents your system without changing its function, Proxies are transparent, thus they are stackable.
It often makes sense to colocate software Proxies or use a multifunctional Proxy to reduce the number of network hops between the clients and the system. However, in a highly loaded system Proxies may be resource-hungry, thus in some cases colocation strikes back.
Pros:
- You get another aspect of your system implemented for you.
Cons:
- Latency degrades.
- More work for admins.
- Another point of possible failure.
Patterns: Proxy, Backends for Frontends.
Goal: let the aspects of communication vary among kinds of clients.
Prerequisite: your system serves several kinds of clients.
If you have internal and external clients, or admins and users, you may want to vary the setup of Proxies for each kind of client, sometimes to the extent of physically separating network communication paths, so that each kind of client is treated according to its bandwidth, priority, and permissions.
Pros:
- It is easy to set up various aspects of communication for a group of clients.
Cons:
- More work for admins as the Proxies are duplicated.
| << Evolutions of a Shared Repository | ^ Evolutions of architectures ^ | Evolutions of an Orchestrator >> |
|---|
CC BY Denys Poltorak. Editor: Lars Noodén. Download the book from Leanpub or GitHub. Generated with odt2wiki.
Analytics
Appendices
- Acknowledgements
- Books referenced
- Copyright
- Disclaimer
-
Evolutions of architectures
- Evolutions of a Monolith that lead to Shards
- Evolutions of a Monolith that result in Layers
- Evolutions of a Monolith that make Services
- Evolutions of a Monolith that rely on Plugins
- Evolutions of Shards that share data
- Evolutions of Shards that share logic
- Evolutions of Layers that make more layers
- Evolutions of Layers that help large projects
- Evolutions of Layers to improve performance
- Evolutions of Layers to gain flexibility
- Evolutions of Services that restructure services
- Evolutions of Services that add layers
- Evolutions of a Pipeline
- Evolutions of a Middleware
- Evolutions of a Shared Repository
- Evolutions of a Proxy
- Evolutions of an Orchestrator
- Evolutions of a Sandwich
- Format of a metapattern
- Glossary
- History of changes
- Index of patterns