Proxy: #
It usually makes little sense to get rid of a Proxy once it is integrated into a 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 that needs low latency. The other drawback of the pattern, 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.
Add another Proxy #
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.
Deploy a Proxy per client type #
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.