TLDR;
Tinder got tired of all their microservices making their own API gateways. So they built one in house and told everyone to use it.
There’s no dumb questions, except this one: What’s an API Gateway?
API gateways are a server that sits in between all the client requests and the actual servers. It’s an in-between server that checks all the requests and does additional things to it before passing it over to the actual server.
Context, context, context.
Tinder has 500+ microservices (pretty insane for a swipe right dating app). If your app is big enough, you’ll build an API Gateway like what Tinder did.
For a long time Tinder didn’t. Instead they used MULTIPLE 3rd party API Gateays AT THE SAME TIME.
Yeah, that didn’t scale and was really annoying to work with. So here’s what they did instead.
TODO: What they did instead.
A senior engineer told me to always talk about the requirements first.
Requirements First…
Before we jump into the full design, lets outline some requirements from the official article (and my simplifications)
A solution to bring all external facing services under one umbrella
Everyone uses the same API gateway
An artifact that could be used by any application team to spin off their API Gateway to scale their application independently
A simple way to get rid of the old 3rd party API gateway.
A framework that could provide the capability for applications to run as a Kubernetes microservice along with other Kubernetes services
It needs to run on kubernetes
A design that could support configuration-driven API Gateway development for increased development velocity
Make this in-house API gateway run using configs
A generic component that could be extended based on Tinder’s custom needs
Make it easy to modify
Adding Request/Response transformations
The Gateway can transform the requests and responses
Custom middleware logic for various features like Bot Detection, Schema Registry, and more
The Gateway should do multiple things like add prechecks and security stuff for everything going through.
Existing API Gateway Solutions?
Tinder considered all these options:
Amazon AWS Gateway, APIgee, Tyk.io, Kong, Express API Gateway, and KrakenD.
They didn’t meet the requirements above. Next best thing is to just build it yourself.
TAG, You’re it
Tinder built their API Gateway and called it the Tinder Api Gateway (cool name right?)
It does everything an API Gateway is supposed to do, except TAG does it off of configuration changes.
Why? Because configs are easy to change so it makes developer lives easier.
The Actual Design
It’s not you, it’s a pretty complicated diagram.
Lets break it down
Some client (like your phone) swipes right on a cute profile
That request goes up to TAG and a route configs figures out which actual backend service the request goes to (Route Config/Handler)
That request then goes to custom filters for cleaning. Some data needs to be scrubbed, some data needs to be added. Sometimes there’s security checks to make sure no one’s spamming.
Then the backend finally receives the request. (Hopefully you match and they also swiped right on you too)
Links and the Official Article!
(Links to official article and sources are available to paid subscribers. They help maintain and support this newsletter!)
Keep reading with a 7-day free trial
Subscribe to Byte-Sized Design to keep reading this post and get 7 days of free access to the full post archives.