Bird
Raised Fist0
Microservicessystem_design~10 mins

Request aggregation in Microservices - Interactive Code Practice

Choose your learning style10 modes available

Start learning this pattern below

Jump into concepts and practice - no test required

or
Recommended
Test this pattern10 questions across easy, medium, and hard to know if this pattern is strong
Practice - 5 Tasks
Answer the questions below
1fill in blank
easy

Complete the code to define the aggregator service endpoint.

Microservices
app.get('/aggregate', async (req, res) => {
  const data = await [1]();
  res.send(data);
});
Drag options to blanks, or click blank then click option'
AfetchDataFromServices
BlistenToRequests
CstartServer
DhandleError
Attempts:
3 left
💡 Hint
Common Mistakes
Using a function that starts the server instead of fetching data.
Using a function that listens to requests instead of aggregating data.
2fill in blank
medium

Complete the code to aggregate responses from two microservices.

Microservices
async function fetchDataFromServices() {
  const [data1, data2] = await Promise.all([
    fetchServiceA(),
    [1]()
  ]);
  return { data1, data2 };
}
Drag options to blanks, or click blank then click option'
AfetchServiceE
BfetchServiceC
CfetchServiceD
DfetchServiceB
Attempts:
3 left
💡 Hint
Common Mistakes
Using a service function that does not exist.
Calling the same service twice.
3fill in blank
hard

Fix the error in the aggregation function to handle failed service calls.

Microservices
async function fetchDataFromServices() {
  try {
    const data = await Promise.all([
      fetchServiceA(),
      fetchServiceB()
    ]);
    return data;
  } catch ([1]) {
    return { error: 'Service call failed' };
  }
}
Drag options to blanks, or click blank then click option'
Ae
Berr
Cexception
Derror
Attempts:
3 left
💡 Hint
Common Mistakes
Leaving the catch block without a variable name.
Using a variable name not declared or inconsistent.
4fill in blank
hard

Fill both blanks to correctly merge and return aggregated data from services.

Microservices
async function fetchDataFromServices() {
  const [dataA, dataB] = await Promise.all([
    fetchServiceA(),
    fetchServiceB()
  ]);
  return { ...dataA[1]...dataB[2] };
}
Drag options to blanks, or click blank then click option'
A,
B;
C+
D&
Attempts:
3 left
💡 Hint
Common Mistakes
Using semicolons or plus signs inside object literals.
Omitting commas between spread objects.
5fill in blank
hard

Fill all three blanks to implement caching in the aggregator service.

Microservices
const cache = new Map();

async function fetchDataFromServices() {
  if (cache.has([1])) {
    return cache.get([2]);
  }
  const data = await Promise.all([
    fetchServiceA(),
    fetchServiceB()
  ]);
  cache.set([3], data);
  return data;
}
Drag options to blanks, or click blank then click option'
A'aggregateKey'
B'cacheKey'
C'dataKey'
D'serviceData'
Attempts:
3 left
💡 Hint
Common Mistakes
Using different keys for cache.has, cache.get, and cache.set.
Using undefined or variable keys inconsistently.

Practice

(1/5)
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