Forem: Ankit Aabad

⚡ How to Respect Rate Limits With Bottleneck

Ankit Aabad — Sat, 28 Jun 2025 03:19:39 +0000

Modern systems often rely on APIs or services that enforce strict limits on how frequently and how many requests can be made — whether due to scalability, fairness, resource protection or your subscription plan.

You might be working with:

An internal rate-limited service
An async job runner that must avoid resource contention
A background task that syncs data without overwhelming a target system

In these cases, trying to "pace" requests with custom code typically leads to:

Fragile setTimeout() logic
Inconsistent behavior under load
Queues that are difficult to debug or scale

That’s where Bottleneck comes in — a lightweight, production-ready scheduling library for Node.js that brings powerful, composable rate-limiting primitives to your async workflows.

🧩 The 3 Core Flags and What They Solve

1. ⏱️ `minTime`: Space Out Requests (RPS)

Problem:

“My API only allows 10 requests per second.”

Solution:

const limiter = new Bottleneck({ minTime: 100 }); // 100ms = 10 RPS

Usage

const fetchData = limiter.wrap(async (input) => {
  return fetch(`https://example.com/api?q=${input}`);
});
// Queue up 200 requests
const inputs = Array.from({ length: 200 }, (_, i) => ({ id: i }));

Promise.all(
  inputs.map((input) => fetchData(input))
).then((results) => {
  console.log("All requests completed!");
});

Ensures 100ms spacing between job starts — giving you consistent pacing.

2. 🔄 `maxConcurrent`: Limit Parallel Jobs

Problem:

“I don’t want more than 3 jobs running at once.”

Solution:

const limiter = new Bottleneck({ maxConcurrent: 3 });

Usage

const processFile = limiter.wrap(async (file) => {
  return compress(file);
});

No matter how many jobs are queued, only 3 run at the same time.

3. 🪣 `reservoir`: Enforce Request Quotas

Problem:

“The API allows only 1000 requests per hour.”

Solution:

const limiter = new Bottleneck({
  reservoir: 1000,
  reservoirRefreshInterval: 60 * 60 * 1000, // 1 hour
  reservoirRefreshAmount: 1000,
});

Usage

const sendEmail = limiter.wrap(async (email) => {
  return smtpClient.send(email);
});

Prevents more than 1000 jobs in a given hour. When the bucket is empty, jobs wait for refill.

🔁 How They Work Together

Bottleneck applies all constraints together:

minTime → controls how fast jobs start
maxConcurrent → limits how many run at once
reservoir → caps total jobs over time

✅ Example

Here is a Sample code to test with Bottleneck, Just change the delay timer.

“I want to send 10 requests per second, at most 3 in parallel, and not exceed 1000 requests per hour.”

Testing

import Bottleneck from "bottleneck";

const limiter = new Bottleneck({
    minTime: 100, // 10 requests per second
    maxConcurrent: 3,
    reservoir: 1000,
    reservoirRefreshInterval: 3600000, // 1 hour
    reservoirRefreshAmount: 1000,
});
function delay(ms) {
    return new Promise((resolve) => setTimeout(resolve, ms));
}
const callAPI = limiter.wrap(async (payload) => {
    await delay(500);
    console.log("finished request for payload:", payload.id);
});

// Queue 100 requests
const inputs = Array.from({ length: 100 }, (_, i) => ({ id: i }));

Promise.all(inputs.map((payload) => callAPI(payload))).then((results) => {
    console.log("All requests completed!");
});

🧪 Quick Flag Guide

Goal	Use
Limit requests per second	`minTime`
Avoid parallel overload	`maxConcurrent`
Respect quota (e.g. 1000/hr)	`reservoir` + refresh
Combine pacing & concurrency	`minTime` + `maxConcurrent`
Full traffic shaping	All 3

🧘 Final Thoughts

The next time you hit a 429 Too Many Requests or crash a service with async overload — don’t use hacks. Use Bottleneck.

✅ Declarative.

✅ Predictable.

✅ Powerful.

Why Single Function Lambdas is a terrible choice for Serverless development.

Ankit Aabad — Sun, 06 Apr 2025 08:28:49 +0000

Single function lambdas for every endpoint is really bad on every possible front, be it developer experience, debugging experience, deployment efficiency, cost or performance.

One common best practice that’s often pushed by serverless advocates is to create a separate Lambda function for every single endpoint. I think that’s a terrible idea. In this post we will examine the arguments from the other side and see why the arguments lack merit, consistency, or real-world practicality.

This push for extreme separation reminds me of Golang. I never really liked the language itself, but I’ve always appreciated one of its core design philosophies: Less is exponentially more. Interestingly, while I don’t think that idea works well in the context of programming language design, it makes a lot of sense when applied to Serverless infrastructure. When building serverless systems, a few cohesive, well-structured Lambdas often result in simpler, more maintainable architectures than a maze of single-function lambdas.

Architect Around Work, Not Routes

HTTP paths are not architectural boundaries — workloads are. Lambdas should be shaped by what they actually do and the dependencies they need to run efficiently.

For example, you might have a Lambda that powers your entire web server. Another for data crunching using an npm package that ships with a rust binary (node polars) leveraging multiple vCpus. A third might handle image processing with sharp, triggered by S3 uploads. And maybe another is dedicated to web scraping where you bundle a headless browser like Puppeteer as Layer to Lambda.

Each of these functions serves a real, functional purpose. They have unique performance characteristics, dependency trees, and compute or configuration needs. This is what meaningful separation looks like — it’s intentional , based on real boundaries, and grounded in how the system actually works.

But carving out a separate Lambda just because one endpoint is /user/login and the other is /user/logout? That’s not applying the Single Responsibility Principle — that’s butchering it in broad daylight.

And if you’re worried about routing flexibility, API Gateway invokes the most specific match. That means you can serve all your generic routes through a single Lambda while still routing specific paths to their own dedicated function. You get targeted isolation where it actually matters — without blowing up your architecture into a hundred micro-lambdas.

The Myth of Fine-Grained Access Control and Blast Radius

One of the most frequently cited justifications for having a separate Lambda for every endpoint is “fine-grained access control” or reducing the “blast radius.” It sounds reasonable at first — give each function the minimum permissions it needs, so if it’s compromised or misbehaves, the damage is limited. But if you take this logic to its natural conclusion, it quickly becomes absurd.

If this principle were applied consistently, you’d also be creating a separate Docker container for every HTTP endpoint in a traditional service. But nobody does that — because it’s obviously overkill and stupid.

The same goes for databases. Serverless advocates often promote single-table design ( with DynamoDB). But hang on — doesn’t that violate “fine-grained access control”? If a createUser Lambda has PutItem access on the whole table, what’s stopping it from writing into an unrelated orders record? Should we now split the table into one-per-entity to reduce the blast radius even further? because Logic is the same. Where do we stop?

This isn’t architectural discipline — it’s paranoia masquerading as best practice. Security and isolation are important — but so is pragmatism. The goal is to build systems that are secure, maintainable, and efficient — not to pass a theoretical purity test.

Don’t believe me. Arc codes is a serverless framework that creates a single IAM role and shares it across all functions. check here and in the playground. Serverless framework is another one that uses single IAM role. check here.

Bundle Size & Cold Starts

One common argument against combining endpoints into a single Lambda (a lambdalith) is that it results in a larger bundle size, which supposedly increases cold start latency. But this concern is often overstated and disconnected from real-world usage patterns.

The truth is: most of your endpoints share the same core dependencies. Your db libraries like node-postgres, drizzle or dynamodb toolbox, zod or arktype for validation all remain the same. Moreover the relation between bundle size and cold start is not linear. The typescript ecosystem is amazing and you have great tree shakeable and optimized libraries. You have honojs for web server, you have zero abstraction ORMs like zapatos.

With a Lambdalith , you unlock powerful reuse: secrets from Parameter Store, database connections, and shared libraries are all initialized once and reused across requests. Since one Lambda handles multiple routes, it receives steady traffic and stays warm, reducing cold starts and latency. But there’s more — even if a Lambda stays warm for 5–6 minutes, DynamoDB’s keep-alive is only ~90 seconds. (personal experience not official number) So if a function isn’t hit frequently, you’ll pay a hidden penalty: a warm Lambda but a cold DB connection. That’s a cold start inside a warm start. Split your app into dozens of tiny Lambdas and you multiply this pain.

The Developer Experience, Debugging Experiece and Deployment Efficiency: Lambdaliths Keep You in Flow

When you’re following the “one Lambda per endpoint” pattern, every new endpoint means deploying a new function — along with its own permissions, logging config, and event source mappings. It’s ceremony without substance. With Lambdalith you can just sam sync instead of sam deploy which is way faster.

And then there’s IAM: ever added PutItem permissions for DynamoDB and realized you now need BatchWriteItem for DynamoDB? Guess what — time to redeploy.

With single function lambdas you get burried under a maze of log groups. With multiple developers and all running their personal stacks this gets amplified. keep searching your logs in the awful AWS UI.

You can btw have a single log group for all your lambdas but no one practices that and it comes with some dope benefits but that is for some other day.

Developer Experience makes you agile not scrum ceremonies or over engineering.

Event Warming and Provisioned Concurrency

When it comes to event warming or provisioned concurrency , Lambdaliths shine. Why? Because you’re keeping one Lambda warm that serves many routes — that’s maximum ROI on your warm instance. A provisioned concurrency of 50 costs $108 per month. If you want to have that for 20 different micro lambdas that is $2160 And many of those might barely get any traffic. I don't recommend Provisioned concurrency in either of the case but because some people use it so adding it.

Over-Engineering Is Good Business (For Them)

Not every “best practice” is about what’s best for your app — sometimes, it’s about what’s best for someone’s business model.

Some third-party vendors charge per Lambda function or CloudFormation stack , so the more you split things up, the more they profit. Even AWS with AWS Inspector charge $0.30 per function per month , and with dozens of Lambdas, that adds up fast.

Lambda Insights also charges you per function.

Datadog charges you per active lambda function.
A single billable function is defined by a unique function ARN. In the case of Lambda@Edge functions, each function in a different region is counted as a separate billable function. : Datadog

More functions also mean more surface area for observability, monitoring, and security tools — all of which feed into paid services.

Even worse, some vendors charge per user , and managing a highly fragmented setup often demands bigger teams. That’s great for them — more seats, more subscriptions — but not for you.

And let’s not forget the gatekeepers who define “proper serverless” in ways that conveniently align with their consulting gigs.

What looks like architectural purity is often just someone else’s revenue stream in disguise.

The “one Lambda per endpoint” mantra may sound clean in theory, but in practice, it creates unnecessary complexity, inflates costs, bloats your infrastructure, and hurts developer experience. Lambdas should be shaped by functional boundaries, not URL patterns. Lambdaliths give you better cold start performance, resource reuse, simpler deployments, saves you on developer cost all without sacrificing maintainability.

Forem: Ankit Aabad

⚡ How to Respect Rate Limits With Bottleneck

🧩 The 3 Core Flags and What They Solve

1. ⏱️ minTime: Space Out Requests (RPS)

2. 🔄 maxConcurrent: Limit Parallel Jobs

3. 🪣 reservoir: Enforce Request Quotas

🔁 How They Work Together

✅ Example

🧪 Quick Flag Guide

🧘 Final Thoughts

Why Single Function Lambdas is a terrible choice for Serverless development.

Architect Around Work, Not Routes

The Myth of Fine-Grained Access Control and Blast Radius

Bundle Size & Cold Starts

The Developer Experience, Debugging Experiece and Deployment Efficiency: Lambdaliths Keep You in Flow

Event Warming and Provisioned Concurrency

Over-Engineering Is Good Business (For Them)

1. ⏱️ `minTime`: Space Out Requests (RPS)

2. 🔄 `maxConcurrent`: Limit Parallel Jobs

3. 🪣 `reservoir`: Enforce Request Quotas