How Niantic switched Pokémon GO to use Envoy
summary
Niantic migrates Pokémon GO from NGINX/Engines to Envoy, running load tests (measured ~20,000 RPS per vCPU) and validating at hundreds of thousands to millions QPS; an initial rollout crashes when Envoy pods receive ~20× expected load and idle-timeout mismatches cause 503s and NXDOMAIN spikes. Engineering builds a custom xDS operator to update clusters without redeploys, adds DNS caching to stop query storms, swaps to count‑based GCLB balancing, and implements a websocket custom filter — migration stabilizes after staged scaling and fixes.
AI-written summary · about
chapters (22)
- 0:00Intro
- 0:23Niantic Mission
- 0:36Niantic Real World Platform
- 2:23Issues to solve
- 3:41Service-gateway overview
- 4:21Service mesh implementation Why not istio and others?
- 5:01Service-gateway Next steps
- 5:33Deployment overview
- 7:14Scaling is a 4 steps process For example, scaling up
- 7:56XDS to the rescue!
- 8:29Current deployment
- 8:43(very) High level plan
- 9:26Preparing production environment
- 10:35IP Deny List
- 10:56Production migration - day 1+
- 13:16Envoy live in Production
- 14:16503 UH: UH (no healthy upstream hosts)
- 15:11Back to load testing
- 15:44Routing and DNS
- 16:16Learnings
- 16:50Extending Envoy: Niantic Frontend
- 17:33Why Niantic chose Envoy
related talks
15mFrom ingress-nginx to Envoy Gateway at Zapier: The...
36mHow Spotify Migrated Ingress HTTP Systems to Envoy
24mHow Spotify Migrated Ingress HTTP Systems to Envoy
38mEnvoy Deep Dive
23mBridging the gap between on-prem and cloud: a story about...
26mIntegrating Stateful Load Balancing At Scale In Envoy
28mEnvoy Project Intro
27mEnvoy - Overview and Update: Senior Envoy Maintainer