The Trials and Success of Adopting Envoy at Tinder
summary
Tinder migrates its Kubernetes fleet to Envoy over ~1 year (2019–2020), ending with 1.6M RPS meshed, 500 services and ~20,000 pods; observability shifts to Prometheus/Thanos with per-route metrics and canary dashboards. Centralizing retries and timeouts removes app-level retry storms, a 10–15s SIGTERM delay eliminates deploy 500s, and a DSL generates Envoy configs. Network features include global rate limiting 200k RPS and locality routing. Control plane starts as a custom EDS control plane on Go, evolving to full XDS with Kafka and S3.
AI-written summary · about
chapters (17)
- 0:00Intro
- 0:22Overview
- 2:26Why Envoy?
- 2:50Downsides of k8s Native Networking envoycon
- 3:41Move to Envoy Based Mesh Network envoycon
- 4:16Migration Hurdles
- 6:06Before and After Mesh
- 7:12Network Tuning
- 9:12Observability Improvements
- 11:48Gotchas: Timeouts and Retries
- 12:30Gotchas: Container lifecycle
- 14:45Global Rate Limiting
- 16:10Mapping The Attackers
- 16:36Configuration
- 17:49EDS Control Plane
- 18:48Firemesh
- 19:49Summary
related talks
10mHow Tinder implemented Envoy global rate limiting at scaleVirtual
29mSafely deploying a 100K line Envoy YAML configuration to production
26mService Mesh Failure Stories at Scale
36mUsing Ambassador to Build Cloud-Native Applications
32mRethinking the Proxy Model: Implementing Envoy as a Node-Scoped Agent
11mA decade of Envoy: From Lyft's Debugging Nightmare to the AI Infra...
33mEnvoy on Fire: A Practical Look at Debugging a Service Mesh
28mEnvoy at Square