Playing to Win: Why Netflix Platform Engineering Chose Fed GraphQL
summary
Netflix replaces multiple client-specific APIs with a unified consumer Edge built on GraphQL and Federation v2, bootstrapping with a monolithic DGS that ported existing FAL core logic so mobile teams could prototype independently. Ownership moves to three domain graphs (growth, discovery, identity) while a Studio graph already spans 200+ domains. Tooling lints and shares schemas, governance stages a first-cut schema then federates it, and the platform scales from hundreds of thousands of RPS toward millions of RPS while retaining central tuning and rollout control.
AI-written summary · about
chapters (12)
- 0:00Intro
- 2:17The Unexpected Journey
- 7:38Marketplaces
- 13:10Going from organic to organic
- 14:30Governance
- 15:51First Cut
- 18:05People
- 20:41Architecture
- 21:37Developer Experience
- 23:00Databacked conversations
- 23:43Whats next
- 25:10Final thoughts
related talks
33mScreens on Shuffle: How Netflix Scales Server‑Driven, Ever‑Changing Pages
38mGraphQL Federation in the Wild
10mEvolution of Application Networking Patterns with GraphQL
30mDeep Learnings Migrating legacy services to Federated GraphQL
28mPanel Discussion: The GraphQL Production Roundtable
23mAdvancing Data Mesh: Building A Stream Processing EcoSystem of Reusable Processors and Datasets
04mBuilding Applications for a Studio in the Cloud at Netflix
34mGraphQL as a Data Mesh Access Layer in Global Banking