Scaling the Data Access by Leveraging GraphQL Federation for Service to Service Communication
summary
Booking.com replaces a single monolithic materialization service that serialized a thousand-field monolithic schema with per-domain subgraphs and a central GraphQL Federation gateway, so each application runs its own materialization query and writes a smaller pre-materialized blob. Result: ownership boundaries clear, fewer irrelevant updates, observable field usage, and ability to drop RocksDB and containerize backends. Federation executes one query across subgraphs and enforces pragmatic limits (e.g., max 1,000 hotels/query); latency is acceptable because materialization runs asynchronously and it works in production.
AI-written summary · about
chapters (6)
- 0:00Introduction and context
- 4:03Business and technical challenges
- 10:05GraphQL adoption and benefits
- 13:19New architecture with GraphQL Federation
- 17:19Results and improvements
- 20:22Q&A session
related talks
23mBuilding the Graph at Booking.com
06mEscape the GraphQL Monolith
23mBuilding the Graph at Booking.com
08mGraphQL: everything you want in one query
40mAgent-Ready Graphs: Engineering the Foundations for Discoverability, Safety, and QoS
46mMoving to GraphQL
36mGraphQL Federation - The @key to Your Platform API Strategy
07mshare how avoid these GraphQL pitfalls