How Tinder built its API Gateway

The Tinder API Gateway (TAG) is a custom-built system that manages all of Tinder's public APIs while enforcing strict security and authorization protocols. It integrates deeply with Tinder's cloud infrastructure, allowing it to scale efficiently without external dependencies. One of its standout features is Route As Configuration (RAC), which enables developers to push updates to production more quickly by easily configuring external routes, streamlining the release process for services like Recommendations, Match, and Revenue APIs.

Tinder operates over 500 microservices within a service mesh, all of which interact through TAG. Given Tinder's global reach in 190 countries, TAG is crucial in scanning for vulnerabilities and protecting against potential security threats, especially from bad actors attempting to exploit the gateway to access sensitive information.

Why Tinder wanted a custom API Gateway

Before developing TAG, Tinder used several API Gateway solutions across various application teams. Each team relied on a different third-party API Gateway, which made management difficult. Since these gateways were built on different tech stacks, sharing reusable components between different gateways was challenging, leading to delays in getting code into production. Another issue was the inconsistent use of session management across their APIs, mainly because the API Gateways weren’t centralized.

Then Tinder wanted to address those key concerns by finding a solution that could:

• Centralize all external-facing services under one system.
• Provide a tool that any application team could use to create their API Gateway, allowing them to scale independently.
• Offer a framework that lets applications run as Kubernetes microservices alongside other Kubernetes services.
• Support configuration-driven API Gateway development to boost development speed.
• Create a generic component that could be customized to fit Tinder’s unique needs.
• Add features like Request/Response transformations and custom middleware logic for things like Bot Detection and Schema Registry.

They also wanted full control over the framework’s development and support to build the gateway exactly as needed. These goals drove the creation of TAG.

Inside of TAG

TAG is a JVM-based framework built on top of Spring Cloud Gateway. It allows application teams at Tinder to easily create their own API Gateway instances simply by writing configurations. TAG centralizes all external-facing APIs and enforces strict authorization and security rules. It extends components like the gateway and global filters of Spring Cloud Gateway to offer pre-built, reusable filters.

These filters can be used for various purposes, such as:

• Weighted routing
• Request/Response transformations
• HTTP to GRPC conversion, and more

TAG was designed with developers in mind, supporting configuration-driven development to make their work easier. It improves development speed, simplifies route and service setup using YAML or JSON configurations specific to each environment, and allows for component reuse by sharing filters across different application routes. TAG leverages key components of Spring Cloud Gateway to build a custom framework that developers at Tinder can use effectively.

TAG features several core components:

1. Routes: Developers can make their endpoints accessible by utilizing Route As a Config (RAC).
2. Service Discovery: TAG uses a Service Mesh to find backend services corresponding to each route.
3. Built-in Filters: TAG includes built-in filters like setPath and setMethod that application teams at Tinder can use.
4. Custom Filters: TAG supports custom filters, allowing teams to write and apply their own logic for specific routes. For example, a custom filter could validate a request before it reaches the backend service.
5. Global Filters: These are similar to custom filters but apply to all routes within a service by default. Examples include an authentication filter or a metrics filter that applies to all routes of an application.

Here is how TAG Builds Routes at Startup:

Spring Cloud Gateway enables TAG to pre-configure all routes and filters, ensuring smooth execution at runtime. This design prevents any configuration processing delay during runtime, allowing TAG to scale easily and handle high traffic efficiently.

A practical example of TAG workflow

When a request is processed using TAG, it follows these steps:

1. Reverse Geo IP Lookup (RGIL): RGIL is a global filter in TAG that maps the client's IP address to a three-digit alpha country code. This is used for rate limiting, request banning, and other functions.
2. Request/Response Scanning: An asynchronous event captures the request details. The Request/Response Scanning Global Filter captures the schema of the request but not the actual data. Amazon MSK streams this data securely, which can be used for various purposes like automatic schema generation and bot detection.
3. Session Management as a Filter: TAG uses a Centralized Global filter for managing and controlling session data.
4. Predicate Matching: TAG matches the path of the incoming request with one of the predefined routes using predicate matching.
5. Service Discovery: The service discovery module in TAG uses Envoy to find the correct egress mapping for the matched endpoint.
6. Pre-Filters: Once the route is identified, the request passes through a series of pre-filters configured for that route. These filters run before the request is sent to the backend service. TAG includes pre-built filters like Weighted Routing and HTTP to GRPC Conversion, and also allows for custom filters, such as Trimming Request Headers.
7. Post-Filters: After the response is received from the backend service, it goes through a series of post-filters configured for that route. These filters run after receiving the response. An example of a post-filter is logging errors.
8. Return Response: After completing the post-filters, the final response is sent back to the client.

References

• Tinder Tech Blog