Inside Booking.com’s Router Rollout: Powering Product and Platform at Massive Scale
summary
Booking.com migrates its GraphQL gateway from Node.js Federation to the Rust Apollo Router and reports handling 12 billion requests/day while cutting gateway CPU/pod needs by about 60% fewer pods and shrinking heavy query processing from ~200ms to ~20ms (roughly 80–90% lower gateway time). Experiments show protobuff→JSON causes no client impact, web vitals improve ~16ms, OpenTelemetry replaces Graphite, and custom Rust plugins implement feature flags, auth, SLI headers and rate‑limit integration.
AI-written summary · about
chapters (22)
- 0:00Booking.com’s router migration intro
- 2:06Scaling Node.js Federation challenges
- 4:13Rust router at massive scale
- 10:30Skepticism to Rust adoption
- 12:36Rust router for enterprise needs
- 16:11Testing strategy for Rust router
- 17:36Performance gains and savings
- 19:17New Rust router capabilities
- 21:01Key takeaways
- 22:27Q&A: Custom rate limiting
- 23:31Q&A: Observability at scale
- 24:37Q&A: Rust router adoption differences
- 25:39Q&A: Page-level experimentation
- 27:01Q&A: Graph changes and entities
- 28:47Q&A: Co-processor plans
- 29:53Q&A: Production testing strategies
- 30:56Q&A: Legacy migration driver
- 31:45Q&A: GraphQL team onboarding
- 32:50Q&A: Apollo Router roadmap
- 34:12Q&A: Subgraph impact and schema
- 34:57Q&A: GraphQL operation discovery
- 36:02Q&A: Router pod scaling
related talks
07mThe future of GraphQL routing
23mBuilding the Graph at Booking.com
23mBuilding the Graph at Booking.com
23mWas It Worth It? Lessons from Implementing Two GraphQL Routers. In JavaScript & Rust
31mLessons from Scaling GraphQL to Half a Billion Requests per Minute
30mHow to Choose a GraphQL Gateway
29mScaling the Data Access by Leveraging GraphQL Federation for Service to Service Communication
30mDeep Learnings Migrating legacy services to Federated GraphQL