Sharding a GraphQL Gateway for Blast Radius Reduction
summary
Airbnb’s Viaduct runs a single-JVM GraphQL gateway for ~600 tenants and >70% of API traffic where one bad query can crash the fleet in 10–15 seconds. They shard traffic via a dispatcher into 30 Kubernetes deployments, assign each operation to two random shards (shuffle sharding) cutting full-overlap to 0.2% full-collision, add dedicated shards (deny/isolate/sync/experiment), cut mitigation from 3 hours → 10 minutes via config, and use bucket sampling for up to a 1000x signal boost on low‑QPS critical ops; tenant-aware sharding is planned.
AI-written summary · about
chapters (13)
- 0:00Introduction to sharding
- 2:05Sharding policy decisions
- 6:45Routing traffic with dispatcher
- 9:16Infrastructure and shard deployment
- 11:05Gaps in standard sharding
- 13:13Dedicated sharding introduction
- 16:04Dedicated sharding routing rules
- 17:31Mitigation speed improvement
- 18:12Canary analysis with dedicated shards
- 20:16Bucket sampling for critical ops
- 22:42Future tenant isolation
- 23:44Evolution of sharding strategy
- 24:26Q&A session
related talks
15mFault isolation using shuffle sharding
31mLessons from Scaling GraphQL to Half a Billion Requests per Minute
59mBuilding Distributed GraphQL APIs
29mScaling the Data Access by Leveraging GraphQL Federation for Service to Service Communication
34mGoing Serverless with GraphQL
46mMoving to GraphQL
01h 05mBuilding Distributed GraphQL APIs
31mEmbracing resiliency in GraphQL-Drop the cache-aside pattern and overcome the...