Implementing Service Aggregation Patterns
1. API Composition Pattern
| Aspect | Detail |
| Definition | Composer service queries multiple services and joins results in memory |
| Use Case | Cross-service queries when CQRS read model not justified |
| Pros | Simple; no extra storage |
| Cons | Latency = slowest call; expensive for large joins |
2. Aggregator Service Pattern
| Property | Detail |
| Role | Dedicated service that orchestrates calls and merges responses |
| Owns | Aggregation logic and DTOs |
| Avoids | Each client doing its own composition |
3. Composite Service Pattern
| Aspect | Detail |
| Definition | Higher-level service composed of lower-level services |
| Layered View | Edge / Composite / Atomic services |
| Watchout | Risk of cascading failures down the layers |
4. Response Aggregation Pattern
| Strategy | Detail |
| All-or-Nothing | Fail entire response if any sub-call fails |
| Partial Response | Return what succeeded; mark failures |
| Best-Effort | Return defaults / cached for failures |
Example: Partial Response
{
"order": { "id": "123", "status": "PAID" },
"shipping": { "error": "service_unavailable", "trackingId": null },
"recommendations": [{ "productId": "p9" }]
}
5. Parallel Service Call Pattern
| Aspect | Detail |
| When | Calls are independent |
| Latency | = max(call1, call2, ..., callN) |
| Implementation | CompletableFuture (Java), Promise.all (JS), goroutines (Go) |
| Tooling | Add per-call timeout; combine with circuit breaker |
6. Sequential Service Call Pattern
| Aspect | Detail |
| When | Each call depends on previous result |
| Latency | = sum of all calls (worst pattern for chains) |
| Mitigation | Avoid chains >3; restructure or pre-fetch |
Warning: Long synchronous chains compound latency and failure probability. P(success) = ∏ p(each).
7. Scatter-Gather Pattern
| Step | Action |
| Scatter | Send same request to N services in parallel |
| Gather | Collect responses |
| Combine | Aggregate (sum, best-of, all) |
| Use Case | Search across shards, multi-vendor price quotes |
8. Partial Response Pattern
| Mechanism | Detail |
| Field Selection | Client requests subset (?fields=id,name or GraphQL) |
| Sparse Fieldsets | JSON:API fields[orders]=id,total |
| Benefit | Smaller payloads; faster mobile |
9. Data Joining Pattern
| Approach | Detail |
| In-Memory Join | Aggregator joins after fetching |
| Materialized View | Pre-joined read model maintained via events |
| Stream Join | Kafka Streams / Flink joins event streams |
| Anti-Pattern | SQL JOIN across service DBs |
10. Content Enricher Pattern
| Aspect | Detail |
| Definition | Augment message with data from external source before forwarding |
| Examples | Add customer name to OrderPlaced event from customer service |
| Where | Stream processor, message gateway, ESB-style mediator |