Gateway Aggregation: Scatter Gather Pattern

The Scatter Gather Pattern
The gateway receives one client request, fans out to multiple backend services in parallel (scatter), collects all responses, and combines them into a single response (gather). A product page request scatters to product, inventory, pricing, and reviews services. Total latency equals the slowest service plus aggregation overhead, not the sum of all service latencies.
Parallel vs Sequential Calls
Parallel calls complete in max(service latencies). Four services at 50ms each complete in ~50ms parallel vs 200ms sequential. However, some calls have dependencies: you cannot fetch user preferences until you know the user ID from authentication. The gateway must model these dependencies and parallelize only independent calls.
Partial Failure Handling
What happens when one of four services fails? Options: Fail entire request: Simple but poor user experience. Return partial data: Product page shows without reviews if reviews service is down. Use cached fallback: Return stale data with a freshness indicator. The aggregation logic must handle missing fields gracefully and indicate data completeness to clients.
💡 Key Insight: Aggregation latency is bounded by your slowest service. A 500ms outlier service makes your entire aggregated response take 500ms+. Consider timeouts that return partial data rather than waiting for slow services.
Response Transformation
Raw service responses rarely match client needs exactly. The gateway transforms and reshapes data: rename fields, filter unnecessary data, convert formats, calculate derived values. A mobile client might need a flattened response while a web client needs nested objects. Transformation adds CPU overhead but reduces client side processing and bandwidth.
Aggregation Complexity
Complex aggregation logic in the gateway risks creating a distributed monolith. If changing the product page requires gateway changes, you have coupled the gateway to business logic. Keep aggregation simple: fetch, combine, transform. Move complex business logic to a dedicated Backend for Frontend (BFF) service that the gateway routes to.

💡 Key Takeaways

✓Scatter gather completes in max(service latencies) not sum: 4 services at 50ms each take ~50ms parallel vs 200ms sequential

✓Partial failure options: fail entire request, return partial data, use cached fallback. Aggregation must handle missing fields.

✓Keep aggregation simple (fetch, combine, transform) to avoid coupling gateway to business logic

📌 Interview Tips

1Calculate the latency benefit: show how parallel calls to 4 services at 50ms each complete in 50ms vs 200ms sequential

2Discuss partial failure strategy: product page can show without reviews rather than failing entirely

3Warn about distributed monolith: if gateway changes for every product page change, aggregation logic is too complex

← Back to API Gateway Patterns Overview