Observability for a Multi-Tenant GraphQL Gateway at Scale
summary
Viaduct runs as one JVM serving ~70% of Airbnb traffic with ~1.5M lines of code, ~600 tenant modules (≈200 teams) and ~200 merges/day, so ownership and metrics must be automatic. The system reads schema annotations to generate schema-driven alerting and enforces ownership per field; behavioral directives drive which fields get detailed metrics, controlling cardinality across ~29k types and ~5k operations. Automatic resolver and dataloader instrumentation plus a calibrated on-time latency metric lets teams pinpoint the guilty tenant (a P95 spike reduced from many suspects to three) without extra tenant work.
AI-written summary · about
chapters (8)
- 0:00Introduction and problem setup
- 4:38Attribution fundamentals
- 7:28Debugging at scale with attribution
- 7:50Alert ownership via schema
- 10:47Cardinality control in metrics
- 14:21Latency attribution with own time
- 17:35Key takeaways and summary
- 19:02Q&A
related talks
32mDesign Observability Solution for Multi-Tenancy Environment
25mUnlocking Insights: Navigating the World of GraphQL Observability
33m6 Years of Distributed GraphQL in Production
27mHow The Guild is using GraphQL at scale
52mIs your JVM app flying blind? Unmask hidden issues with Observability superpowers!
01h 05mWorkshop: Scaling and Securing API Development with a GraphQL Platform
07mshare how avoid these GraphQL pitfalls
01h 07mGraphQL: Smooth Schemas and Rough Edges