Um schema, vários times: schema stitching e federação

Resposta esperada

O problema: você quer um endpoint GraphQL único pro cliente, mas cada time é dono de um domínio (usuários, pedidos, catálogo) e não quer editar um schema compartilhado gigante. Federação (Apollo Federation é o padrão de fato): cada serviço (subgraph) define a parte do schema que possui, e pode ESTENDER tipos de outro serviço (o serviço de pedidos adiciona um campo `pedidos` ao tipo `User` sem ser dono de `User`). Um gateway compõe os subgraphs num supergraph e, em runtime, decompõe a query do cliente em subconsultas pra cada serviço e junta os resultados (resolvendo referências por chave). Schema stitching é o antecessor, mais manual. Ganhos: times deployam independente, ownership claro. Custos: latência do gateway + N chamadas, complexidade de composição, e um contrato de federação pra manter. Vale pra org grande; overkill pra um time.