How Tinder implemented Envoy global rate limiting at scaleVirtual
summary
Tinder migrates its Kubernetes fleet to an Envoy sidecar mesh and moves rate limiting out of apps into a Go-based rate limit service that proxies Redis through Envoy, handling about 200,000 requests/sec policed and meshing ~1.6 million rps at peak. Config is hot-reloaded via a ConfigMap, thresholds live in the service, analytics sink to S3 for blocklisting and ML enrichment, a 20 ms fail-open timeout is enforced and 5,000 rps per service pod is a practical benchmark.
AI-written summary · about
chapters (9)
- 0:00Intro
- 0:51Tinder's service mesh journey
- 3:03Previous RL implementations
- 4:01Envoy RL - Why's it good?
- 5:32Ratelimit service
- 6:30Envoy RL - Config
- 7:17Envoy RL at Tinder
- 9:02Bots are everywhere!
- 9:28Tips / Try it out!
related talks
22mThe Trials and Success of Adopting Envoy at Tinder
26mRunning Envoy at the Edge
10mLightning Talk: Envoy @ Netflix
25mUse Envoy + Knative to auto scale Java RPC micro service
16mLightning Talk: More Intelligent Global Rate Limiting
26mIntegrating Stateful Load Balancing At Scale In Envoy
26mTraffic Management w. Rate Limiting to Ensure API Scalability & Resiliency
32mRethinking the Proxy Model: Implementing Envoy as a Node-Scoped Agent