Shifting Instagram Development Towards Monolith Server Via Federated Schema
summary
Instagram migrates its Python monolith to Facebook’s PHP monolith by building a unified SDL and a federated executor in each server that loads persisted query plans and routes fields across stacks; the media model has ~800 direct and ~5,000 nested fields, ads migration touches ~600 fields, and >50% of traffic already runs on the FB monolith. Key pieces: route directive for build‑time routing, dynamic query plan using skip/include variables for per‑request routing, concurrent cross‑stack execution, flattening/duplication to avoid latency, and non‑nullable push‑safety rules requiring split commits.
AI-written summary · about
chapters (8)
- 0:00Introduction and overview
- 2:50Federated GraphQL migration strategy
- 4:34Federated infrastructure components
- 8:31Server definitions and schema unification
- 13:50Push safety and compatibility challenges
- 18:09Real-world monetization use case
- 24:17Migration progress and results
- 25:00Q&A on authorization and routing
related talks
27mGraphQL at Facebook
21mThe Art of Changing Large Software Systems in Place
43m"Monoliths are Simpler" and other lies we tell ourselves
32mQuietly Strangling the Monolith - a real-world migration of a high traffic monolith
35mLegacy Monolith to Microservices
36mThe Art of Decomposing Monoliths
35mFrom Dinosaurs to Snakes - Decomposing the Enterprise Monolith
25mTransforming the Monolith into a Federated Graph