Request aggregation in Microservices - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ Architecture

intermediate

Designing a request aggregator for microservices

You need to design a request aggregator that collects data from three microservices: User Service, Order Service, and Inventory Service. Which architectural pattern best suits this scenario to minimize client complexity and improve performance?

A Client-side aggregation where the client calls each service separately and combines results.

B API Gateway pattern that aggregates responses from all three services before returning to the client.

C Direct service-to-service calls where User Service calls Order Service and Inventory Service internally.

D Use a message queue to asynchronously collect data from services and send to client.

💡 Hint

Think about reducing the number of calls the client makes and centralizing aggregation.

The API Gateway pattern centralizes aggregation, reducing client complexity and improving performance by combining data from multiple services before responding.

❓ scaling

intermediate

Scaling a request aggregator under high load

Your request aggregator receives thousands of requests per second, each requiring data from multiple microservices. What is the best approach to scale the aggregator to handle this load efficiently?

A Cache all microservice responses indefinitely to avoid calling them.

B Increase the CPU and memory of a single aggregator instance to handle all requests.

C Make the aggregator synchronous and block requests until all microservices respond.

D Deploy multiple instances of the aggregator behind a load balancer and use asynchronous calls to microservices.

💡 Hint

Consider horizontal scaling and non-blocking calls.

Deploying multiple aggregator instances behind a load balancer allows horizontal scaling. Using asynchronous calls reduces waiting time and improves throughput.

❓ tradeoff

advanced

Tradeoffs in synchronous vs asynchronous request aggregation

When aggregating requests from multiple microservices, what is a key tradeoff between synchronous and asynchronous aggregation approaches?

A Asynchronous aggregation guarantees data freshness while synchronous aggregation always returns cached data.

B Synchronous aggregation always scales better than asynchronous aggregation.

C Synchronous aggregation offers simpler error handling but higher latency; asynchronous aggregation reduces latency but complicates error handling.

D Synchronous aggregation requires message queues, asynchronous does not.

💡 Hint

Think about latency and complexity in error handling.

Synchronous aggregation waits for all services, increasing latency but simplifying error handling. Asynchronous aggregation can reduce latency by processing responses as they arrive but requires more complex error and state management.

🧠 Conceptual

advanced

Understanding request fan-out and fan-in in aggregation

In request aggregation, what do the terms 'fan-out' and 'fan-in' refer to?

A 'Fan-out' is sending requests to multiple services; 'Fan-in' is collecting and combining their responses.

B 'Fan-out' means scaling horizontally; 'Fan-in' means scaling vertically.

C 'Fan-out' is combining responses; 'Fan-in' is sending requests to services.

D 'Fan-out' is caching data; 'Fan-in' is invalidating cache.

💡 Hint

Think about the direction of requests and responses.

'Fan-out' describes the process of sending multiple requests to different services. 'Fan-in' is the process of gathering those responses and combining them into one.

❓ estimation

expert

Estimating capacity for a request aggregator

Your request aggregator handles 10,000 requests per second. Each request fans out to 4 microservices. Each microservice call takes 50ms on average. Assuming the aggregator calls services in parallel and has negligible processing overhead, what is the minimum number of aggregator instances needed to handle the load with a 1-second response time SLA?

A At least 25 instances, because each instance can handle 400 requests per second.

B At least 200 instances, because each instance can handle 50 requests per second.

C At least 10 instances, because parallel calls reduce total time to 50ms per request.

D At least 400 instances, because each microservice call adds 50ms sequentially.

💡 Hint

Calculate requests per instance based on response time and concurrency.

Each request takes 50ms due to parallel calls. One instance can handle 1 / 0.05 = 20 requests concurrently. To meet 10,000 requests per second, 10,000 / 400 = 25 instances are needed.