Case study · day job, genericized

Leading Apollo Federation adoption across many teams.

A genericized account of leading GraphQL Federation as an org-wide capability. No employer-proprietary detail; the lessons are the deliverable.

When a single GraphQL schema becomes the contract between dozens of teams and hundreds of clients, federation isn't just a technical choice — it's an organizational one. The technology is the easy part. The hard part is governance, migration, and the social architecture you build around it.

What "leading adoption" actually meant

Three concurrent jobs, none of which were on the original ticket:

1. Designing the federation platform itself — the gateway, the subgraph patterns, the schema-check pipeline, the observability hooks.
2. Internal champion — convincing teams who had perfectly good REST or monolithic GraphQL services that the migration was worth it for them, not just for the platform team.
3. Schema reviewer of last resort — when an entity needs to be federated, who decides what the canonical type looks like? Often, me.

The technical wins (briefly)

• A subgraph pattern that lets teams ship their first federated service without becoming federation experts first.
• Schema-check CI that catches breaking changes before they hit the gateway, with allowlists for intentional breakage.
• Observability that surfaces per-subgraph latency and per-field usage so teams can deprecate confidently.
• Clear ownership boundaries between subgraph teams and the platform team, so escalation paths exist and don't all land on me.

The non-technical wins (the actual hard part)

• A federation guild — a recurring, cross-team space where subgraph owners share patterns, complaints, and migration scars. This did more for adoption than any document.
• Schema review as a teaching moment, not a gatekeeping ritual. Reviewers leave links to docs and prior decisions, so the next reviewer on the next team has shorter ramp-up.
• A paved migration path. Teams choose when to federate. When they do, the work is mostly copy-paste from the showroom subgraphs and a schema review.
• A clear story for deprecation — teams need to know how to retire a federated field, not just add one.

Result

• A federated graph teams adopt voluntarily, not by mandate.
• The first three subgraphs became the showroom: every team after copies the patterns, with shorter ramp-up each time.
• A schema-check pipeline that catches breaking changes before the gateway sees them, with allowlists for intentional breakage.
• A federation guild that did more for adoption than any internal doc.

What this shows

• I take ambiguous platform-shaped problems and turn them into something the rest of the org can build on.
• I think about adoption as a product surface. Internal teams are users; the metric I optimize for is "time from idea to a usable federated graph for it."
• I write patterns other engineers can copy. The gateway code is the easy part; the real work is making the next team's first day cheap.
• I'm comfortable being the schema reviewer of last resort and the internal champion at the same time.

Want to talk federation?

I take a small slate of consulting engagements each quarter on federation rollouts and graph governance. Get in touch; happy to compare notes even if it's not a fit.