I am considering 2 architectural design using Tyk: Approach 1 & Approach 2.
This is Approach 1:
This is Approach 2:
In Approach 1, a load balancer routes to different instances of Tyk OSS gateway. And each gateway has its own redis.
In Approach 2, a load balancer routes to different instances of Tyk OSS gateway. Each gateway points to a redis cluster.
I have some questions about these 2 approaches.
- What is the pros and cons for approach 1 & approach 2?
- What is the purpose of a redis cluster?
- If I want to implement approach 2, is there any guides/ documents for it? Let’s say I use docker compose to create the Tyk OSS, and how to point to a redis cluster?
Hey @maantarng - the appropriate architecture really depends on your use case for Tyk, but as you have suggested a load balancer will distribute incoming traffic across a number of gateways, you should use architecture approach 2, as shown in the diagram on our “get started with OSS” page here: Get Started with OSS
The shared Redis will ensure that rate limits, quotas and keys are consistent across gateways. This is important as your load balancer will distribute calls across all of your gateways (randomly I presume, not routing according to profile of the traffic), so we need consistency across the gateways. The shared Redis will ensure that all gateways have the same view.
Hi @James Thanks for your explanation and help.