Architecture
A GraphQL federation architecture diagram with an Apollo Gateway building query plans and fanning out to User, Product, and Review subgraphs, each owning its schema and database, with response stitching into a unified GraphQL result. This template models the federated GraphQL approach where multiple teams independently develop and deploy their subgraphs while clients see a single unified API. Ideal for organizations scaling GraphQL across multiple teams and services.
Full FlowZap Code
Client { # Client Application
n1: circle label:"GraphQL Query"
n2: rectangle label:"Send to Gateway"
n3: rectangle label:"Receive Unified Response"
n4: circle label:"Render UI"
n1.handle(right) -> n2.handle(left)
n2.handle(bottom) -> Gateway.n5.handle(top) [label="POST /graphql"]
n3.handle(right) -> n4.handle(left)
}
Gateway { # Apollo Federation Gateway
n5: rectangle label:"Parse GraphQL Query"
n6: rectangle label:"Build Query Plan"
n7: rectangle label:"Fan-Out to Subgraphs"
n8: rectangle label:"Merge Responses"
n9: rectangle label:"Return Unified Result"
n5.handle(right) -> n6.handle(left) [label="AST"]
n6.handle(right) -> n7.handle(left) [label="Execution Plan"]
n7.handle(bottom) -> Subgraphs.n10.handle(top) [label="User Fields"]
n7.handle(bottom) -> Subgraphs.n12.handle(top) [label="Product Fields"]
n7.handle(bottom) -> Subgraphs.n14.handle(top) [label="Review Fields"]
n8.handle(right) -> n9.handle(left) [label="Stitched"]
n9.handle(top) -> Client.n3.handle(bottom) [label="JSON"]
}
Subgraphs { # Federated Subgraphs
n10: rectangle label:"User Subgraph"
n11: rectangle label:"User Database"
n12: rectangle label:"Product Subgraph"
n13: rectangle label:"Product Database"
n14: rectangle label:"Review Subgraph"
n15: rectangle label:"Review Database"
n10.handle(right) -> n11.handle(left) [label="Query"]
n12.handle(right) -> n13.handle(left) [label="Query"]
n14.handle(right) -> n15.handle(left) [label="Query"]
n11.handle(top) -> Gateway.n8.handle(bottom) [label="User Data"]
n13.handle(top) -> Gateway.n8.handle(bottom) [label="Product Data"]
n15.handle(top) -> Gateway.n8.handle(bottom) [label="Review Data"]
}
Why This Workflow?
A monolithic GraphQL server becomes a deployment bottleneck when multiple teams contribute to the same schema. GraphQL federation allows each team to independently develop, deploy, and scale their own subgraph while the gateway automatically composes them into a single unified API for clients.
How It Works
- Step 1: The client sends a single GraphQL query to the Apollo Federation Gateway.
- Step 2: The gateway parses the query and builds an execution plan identifying which subgraphs own which fields.
- Step 3: Parallel requests are fanned out to User, Product, and Review subgraphs.
- Step 4: Each subgraph queries its own database and returns its portion of the response.
- Step 5: The gateway stitches all subgraph responses into a single unified GraphQL result.
- Step 6: The composed response is returned to the client as if it came from a single API.
Alternatives
Schema stitching is an older approach that requires manual configuration. A monolithic GraphQL server is simpler but creates team coupling. REST with API composition achieves similar results without GraphQL. This template shows the federated approach for multi-team GraphQL.
Key Facts
| Template Name | GraphQL Federation Architecture |
| Category | Architecture |
| Steps | 6 workflow steps |
| Format | FlowZap Code (.fz file) |
Related templates
Architecture
A microservices API gateway architecture diagram showing request routing, JWT authentication, rate limiting, service discovery, and response aggregation across distributed backend services. This template models the entry point for all client traffic in a microservices ecosystem, enforcing security policies before requests reach internal services. Ideal for platform engineers designing scalable API infrastructure with centralized cross-cutting concerns.
Architecture
A service mesh architecture diagram with Istio or Linkerd sidecar proxies handling mTLS encryption, traffic policies, circuit breaking, and distributed tracing across microservices. This template visualizes how a service mesh abstracts networking concerns away from application code, enabling zero-trust communication between services. Essential for teams adopting service mesh infrastructure to improve observability and security.
Architecture
A database-per-service architecture diagram where each microservice owns its dedicated data store, with event-driven synchronization via Kafka for cross-service data consistency. This template demonstrates the core microservices data isolation principle, showing how PostgreSQL and MongoDB coexist in a polyglot persistence strategy. Critical for architects enforcing service autonomy while maintaining eventual consistency.
Architecture
A microservices decomposition architecture diagram organized by business capabilities: Identity, Product Catalog, Pricing, and Order Fulfillment, each with independent data stores and APIs. This template shows how to break a monolith into services aligned with business domains, using a Backend-for-Frontend (BFF) pattern for client-specific aggregation. Useful for architects planning domain-driven microservice boundaries.
Architecture
A strangler fig migration architecture diagram showing the incremental replacement of a legacy monolith with new microservices, using a routing layer to split traffic between old and new systems. This template models the proven migration strategy where new features are built as microservices while legacy endpoints are gradually retired. Essential for teams modernizing legacy systems without risky big-bang rewrites.
Architecture
A service discovery architecture diagram with Consul or Eureka registry, client-side load balancing, health check heartbeats, and automatic instance registration and deregistration. This template visualizes how microservices dynamically locate each other without hardcoded endpoints, enabling elastic scaling and self-healing infrastructure. Key for platform teams building resilient service-to-service communication.