← Back to list

Here’s why Request Batching still the most underrated Trick!

You have a service approveData() . It works perfectly for 1 entry at a time.

Ketan Kauntia · 2026-03-23 20:00 · 0 claps · 2.2 min read
#design-systems #batching #dbms
Open on Medium ↗
Wiki topics: PRD · Product Design

Here’s why Request Batching still the most underrated Trick!

Batching vs Sequential db Calls ( image credits to the respective owner )

Batching vs Sequential db Calls ( image credits to the respective owner )

You have a service approveData() . It works perfectly for 1 entry at a time.

Our Task : We now need to extend/build on top of this service for multiDataApproval.

What will we do? -> Get a list of all the id’s to be approved and loop over the pre-exisiting approveData() right? Code won’t break and it will be easy for us.

for (const id of ids) {
  await approveData(id);
}

Nope!

Here’s what I learnt,

If we loop over the approveData(), it makes 1 db call in each iteration. So if we loop over a list, it’s N db Calls !!

UPDATE table SET approved = true WHERE id = 1;
UPDATE table SET approved = true WHERE id = 2;
..
..
UPDATE table SET approved = true WHERE id = N;

What’s the better approach? Nah. think from 1st principles. Whats the issue? N db calls, right? what if we we make only 1 db call??

Yep, this is what batching is all about. Just a fancy term.

Think in this way, You own a shop. You have received products for your business. Now, wanted a list of all the bills you need to pay for right? so, instead of checking it one by one, why not, make one db call by sending all the bill id’s and check whether we “received” the products or not?

UPDATE approvals SET status = 'recieved' WHERE id IN (...);

okay. there are other options as well as in transactions, Parallel Processing, Queues, but it’s for later.

BUT BUT BUT, hold on.

There can be instances where you might be implementing batching, but it might be a partial batching. (yep, Iam guilty of it as well)

This is where many people (including me) mess up. We might think we are batching because we are using something like this :

updateMany()

findMany()

But internally, you might still be:

  • Fetching records one-by-one OR
  • Validating one-by-one OR
  • Triggering side effects per record

Example, We run an e-commerce system and want to apply a 10% discount to a list of product IDs.

async function applyDiscount(productIds) {
  // Batching done here..
  const products = await db.products.findMany({
    where: { id: { in: productIds } }
  });

  for (const product of products) {
    const newPrice = product.price * 0.9;

    // ❌ Still N DB writes
    await db.products.update({
      where: { id: product.id },
      data: { price: newPrice }
    });
  }
}

Even though we did find all the products in 1 db call, later on in the code, we still went for single updates ( writes happening one-by-one )..

So, what can we use?

await db.products.updateMany({
  where: { id: { in: productIds } },
  data: {
    price: {
      multiply: 0.9
    }
  }
});

So, the Key Takeaway from the entire thing is?

when working at scale for N entries/data, try checking if you can use .many() to reduce the db calls to 1 instead of N calls.

updateMany()

findMany()

insertMany()

[ Technically, a bit wrong, but in layman terms to find patterns, this can still be used. ]

That’s it! ( I learnt it better while writing this to explain it to you’ll )


메타데이터
post_id
341fbc64fc8a
slug
heres-why-request-batching-still-the-most-underrated-trick-341fbc64fc8a
url
https://medium.com/@ketankauntia/heres-why-request-batching-still-the-most-underrated-trick-341fbc64fc8a
canonical_url
https://medium.com/@ketankauntia/heres-why-request-batching-still-the-most-underrated-trick-341fbc64fc8a
author_url
https://medium.com/@ketankauntia
status
ok
fetched_at
2026-06-09 15:37:30