Building the Graph at Booking.com
summary
Booking.com replaces parts of a 25-year monolith with a federated graph that first migrates the search results and property pages, then mobile by wrapping the REST BFF with a GraphQL wrapper around REST BFF. Adoption yields measurable wins: development cycles improve up to 40% faster time-to-market, and traffic grows from ~50→100B operations per 90 days with peaks around 1.6B/day. Pain points include increased backend call pressure from composable queries, a paused client-side rollout for a potential data leak, and reconciliation of legacy field types.
AI-written summary · about
chapters (12)
- 0:00Modernizing Booking.com
- 1:50Monolithic system challenges
- 3:15Selling the graph internally
- 6:45Migration to distributed architecture
- 8:08Modernizing search and property pages
- 9:12Migrating mobile clients
- 10:58Lessons learned
- 13:26GraphQL schema-first benefits
- 15:09Development speed impact
- 16:54Centralizing translations
- 18:19Graph growth and future plans
- 20:27Q&A
related talks
40mAgent-Ready Graphs: Engineering the Foundations for Discoverability, Safety, and QoS
29mScaling the Data Access by Leveraging GraphQL Federation for Service to Service Communication
30mDeep Learnings Migrating legacy services to Federated GraphQL
38mInside Booking.com’s Router Rollout: Powering Product and Platform at Massive Scale
33mBooking.com tech modernisation
34mRealtor.com's Technological & Cultural Transformation with GraphQL
35mA Wild GraphQL Rollercoaster Ride a Federated GraphQL Adoption Story
46mMoving to GraphQL