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.

Practice

1. What is the main purpose of request aggregation in microservices?

easy

A. To cache responses from a single microservice

B. To split a large service into smaller microservices

C. To handle database transactions across services

D. To combine data from multiple microservices into a single response

Solution

1. Step 1: Understand request aggregation concept

   Request aggregation means collecting data from multiple microservices to form one combined response.

2. Step 2: Identify the main goal

   The goal is to reduce multiple client calls into one, improving efficiency and user experience.

3. Final Answer:

   To combine data from multiple microservices into a single response -> Option D

4. Quick Check:

   Request aggregation = combine multiple responses [OK]

Hint: Aggregation means combining multiple service responses [OK]

Common Mistakes:

• Confusing aggregation with service splitting
• Thinking it only caches data
• Mixing aggregation with transaction management

2. Which of the following is the correct way to implement a request aggregator in a microservices architecture?

easy

A. Make parallel calls to all required microservices and aggregate responses asynchronously

B. Make sequential calls to each microservice and combine results synchronously

C. Call only one microservice and ignore others

D. Use a database trigger to combine data from microservices

Solution

1. Step 1: Review aggregator call patterns

   Efficient aggregators call multiple services in parallel to reduce total wait time.

2. Step 2: Identify correct implementation

   Parallel asynchronous calls improve performance and user experience compared to sequential calls.

3. Final Answer:

   Make parallel calls to all required microservices and aggregate responses asynchronously -> Option A

4. Quick Check:

   Parallel async calls = best aggregator practice [OK]

Hint: Use parallel async calls for faster aggregation [OK]

Common Mistakes:

• Using sequential calls causing slow responses
• Ignoring some microservices in aggregation
• Trying to use database triggers for aggregation

3. Consider this pseudocode for a request aggregator:

async function aggregate() {
  const user = await getUser();
  const orders = await getOrders(user.id);
  const payments = await getPayments(user.id);
  return { user, orders, payments };
}

What is the main problem with this code?

medium

A. It does not handle errors from getUser

B. It calls getOrders and getPayments sequentially, increasing total response time

C. It returns data in the wrong format

D. It calls getUser multiple times unnecessarily

Solution

1. Step 1: Analyze call sequence

   The code waits for getUser, then calls getOrders and waits, then calls getPayments and waits, all sequentially.

2. Step 2: Identify inefficiency

   Calling getOrders and getPayments one after another increases total wait time unnecessarily.

3. Final Answer:

   It calls getOrders and getPayments sequentially, increasing total response time -> Option B

4. Quick Check:

   Sequential calls = slower aggregation [OK]

Hint: Parallelize independent calls to reduce wait time [OK]

Common Mistakes:

• Assuming error handling is missing
• Thinking return format is incorrect
• Believing getUser is called multiple times

4. You have a request aggregator that calls three microservices in parallel. Sometimes, one service fails and causes the whole aggregation to fail. How can you fix this?

medium

A. Cache the failed service response permanently

B. Retry the failed service indefinitely until it succeeds

C. Ignore errors and return partial data with error info for failed services

D. Stop calling other services if one fails

Solution

1. Step 1: Understand error impact in aggregation

   If one service fails, the aggregator should still return available data to avoid full failure.

2. Step 2: Choose error handling strategy

   Returning partial data with error info improves user experience and system resilience.

3. Final Answer:

   Ignore errors and return partial data with error info for failed services -> Option C

4. Quick Check:

   Partial data + error info = robust aggregation [OK]

Hint: Return partial results with errors, don't fail whole aggregation [OK]

Common Mistakes:

• Retrying endlessly causing delays
• Stopping all calls on one failure
• Caching errors permanently causing stale data

5. You design a request aggregator for a shopping app that calls user, orders, and payment microservices. To improve scalability, which design choice is best?

hard

A. Use asynchronous parallel calls with timeout and fallback data for each microservice

B. Call microservices sequentially and cache all responses for 24 hours

C. Aggregate data in a single monolithic service instead of microservices

D. Make synchronous calls and block until all microservices respond

Solution

1. Step 1: Consider scalability needs

   Parallel async calls reduce latency and improve throughput under load.

2. Step 2: Add timeout and fallback

   Timeouts prevent long waits; fallback data keeps user experience smooth if a service is slow or down.

3. Step 3: Evaluate other options

   Sequential calls and long caching reduce freshness and responsiveness; monolith loses microservices benefits; synchronous blocking hurts scalability.

4. Final Answer:

   Use asynchronous parallel calls with timeout and fallback data for each microservice -> Option A

5. Quick Check:

   Async parallel + timeout + fallback = scalable aggregator [OK]

Hint: Combine async calls with timeout and fallback for best scalability [OK]

Common Mistakes:

• Using sequential calls causing slow response
• Relying on stale cached data too long
• Ignoring microservices benefits by monolith design