5.3 Offload to Gateway
Move common functionality to a gateway to offload backend servicesThis pattern is based on Gateway Offloading by [50]. It is part of the three patterns sometimes called an API Gateway, as detailed in § 4.1.7. Of the three, this one is most prone to its pitfalls but can nevertheless be helpful in some scenarios.
The original name seems to imply that it is the gateway itself being offloaded. Therefore, this work uses the term Offload to Gateway instead, which should better denote the direction of the offloading whilst preserving recognisability.
5.3.1 Context
When decomposing a system into multiple services, common problems may arise, such as caching, logging, monitoring, 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 in many scenarios, this pattern may 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 (see fig. 8).
5.3.3 Potential issues
Similarly to Gateway Routing, 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 on potential security issues inherent to such a design.
5.3.4 Example
ExampleEshop already uses a gateway to route requests to correct services and need to employ rate limiting to prevent abuse. As 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 in the gateway itself.
5.3.5 Related patterns
This pattern builds upon Gateway Routing, as it must be a single entry point
Patterns implementable in a gateway include Rate Limiting, Competing Consumers, Circuit Breaker, Retry and Health Monitoring. However, see the warnings in the previous section
One possible mitigation of these issues is to separate the gateway into multiple Backends for Frontends, reducing its overall scope and overlap. Another solution can be to use small services deployed alongside applications to offload some concerns, such as an Ambassador, which can handle network-related shared functionality, or a Sidecar, which can handle isolated concerns
Simplify the client instead by using Aggregating Gateway
A gateway can communicate with an Identity Provider 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]