Distributed Application Architecture Patterns

4.1 Gateway Routing

Abstract service locations from the clients

This pattern is based on Gateway Routing by [45], Virtual Endpoint by [13, p. 64], and the API routing patterns by [46]. Hohpe et al. define this pattern more generically with the Message Router and Content-Based Router in 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 on why this work breaks it down, see § 4.1.7.

When 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. The easiest solution is to create a common routing service – a Gateway Router.

4.1.1 Context

Apply this pattern if 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 working instances in case of failure or overload

4.1.2 Solution

Introduce a singular gateway component (see fig. 4). Clients interact with the system only through this component, containing all the necessary rules to route the requests. This can be based on several criteria, such as the hostname, URL, port or header. The gateway then forwards the request to the appropriate service. This way, the clients never need to know the actual service locations.

Figure 4: 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 common techniques to reduce resiliency in similar situations. Another important aspect is the increase in latency due to an added jump in the requests and the introduction of a possible bottleneck to the system.

From a higher point of view, introducing this pattern makes it a very appealing point to add more features. This can accentuate the problems outlined above. [3, p. 162]

4.1.4 Example

ExampleEshop uses different APIs for its different frontend. In order to avoid having to update all its apps after changes in deployments, it uses a single entry point that routes the requests to the correct backend based on the path. Thanks to the amount of control this gives them, they can also use it to test new versions of the backend services, run experiments or re-route traffic in case of failures.

4.1.6 Further reading

4.1.7 API Gateway

Gateway routing is sometimes considered part of an API Gateway pattern. However, that pattern, by definition, is a set of multiple functionalities, and that coupling can lead to it being sometimes considered almost an anti-pattern [3, p. 162]. However, these discrete functionalities do not need to be implemented in one system. They can even be necessary in some use cases, so this work adopts the naming scheme propagated by [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.