Adaptive Rate Limiting with Redis and Lua

Debjit Dey — Tue, 28 Apr 2026 17:36:33 +0000

Making Rate Limiting Correct Under Concurrency

Most rate limiting tutorials stop at the single-instance case.
That’s fine for learning, but it breaks quickly in production.

Once you have multiple instances and real traffic patterns, the problem changes.
It’s no longer just about picking an algorithm — it’s about correctness under concurrency.

This article walks through what actually goes wrong and how to fix it.

The In-Memory Trap

The first implementation most people write looks like this:

keep a counter in memory
increment on each request
reject when the limit is reached

This works perfectly in a single instance.

Now deploy two instances.

Each instance has its own counter. A client can exceed your intended limit just by hitting different instances.

At that point, you don’t have a rate limiter anymore.
You have a suggestion.

Redis Fixes Distribution, Not Concurrency

The next step is moving state to Redis.

Now all instances share the same counters. Good.

A typical implementation looks like this:

Read current count from Redis
Check against limit
Increment and write back

This seems correct, but it isn’t.

These are separate operations. Under concurrent load:

two requests read the same value
both pass the check
both increment

Now your limit is no longer strict. It’s approximate.

The Real Problem: Atomicity

The issue isn’t Redis.

It’s that the decision is split across multiple steps.

What you need is:

a single, atomic operation that reads state, applies logic, and updates state

The Fix: Lua Scripts in Redis

Redis supports Lua scripts that execute atomically.

No other command runs between the start and end of the script.

Instead of multiple round trips:

read state
apply limiter logic
update state
return decision

You do everything inside one script.

Example (simplified):

local current = redis.call("GET", KEYS[1]) or 0
if tonumber(current) >= tonumber(ARGV[1]) then
  return {0, current}
end

current = redis.call("INCR", KEYS[1])
redis.call("EXPIRE", KEYS[1], ARGV[2])

return {1, current}

This ensures:

no race conditions
consistent decisions across instances
predictable behavior under load

Where Algorithms Fit In

At this point, you can plug in different strategies:

Token Bucket → allows bursts, smooths over time
Sliding Window → more accurate but heavier
Leaky Bucket → enforces steady flow

But here’s the key point:

The algorithm matters less than where the decision happens.

If your logic isn’t atomic, the algorithm won’t save you.

Static Limits Miss Real Traffic Behavior

Even with correct enforcement, static limits are too rigid.

Real traffic looks like:

legitimate bursts
scrapers probing endpoints
repeated identical requests
denial loops

A fixed limit treats all of these the same.

Adding a Behavior Layer

A simple improvement is to track short-term behavior:

request volume over a short window (burst detection)
repeated request fingerprints
number of unique routes hit (scan detection)
repeated denials

This produces a basic risk score.

That score maps to tiers:

normal
elevated
suspicious
blocked

The important part is separation:

Limiter → enforces limits
Policy → decides how strict to be

This keeps the system easier to reason about and tune.

Tradeoffs

This approach is not free.

Lua scripts add complexity
debugging moves closer to Redis
Redis becomes a critical dependency

But for systems that need consistency under concurrency, the tradeoff is worth it.

Key Takeaway

The biggest lesson is not about token buckets or sliding windows.

It’s this:

Correctness in rate limiting comes from atomic decision-making.

Once you ensure:

a single source of truth
atomic execution
consistent state across instances

the rest becomes much easier.

Closing

I built this approach into a small system to explore the problem end-to-end.

If you’re interested in seeing a full implementation (TypeScript + Redis + Lua), you can check it out here:

👉 https://github.com/debjit450/arce

If you’ve dealt with this problem in production, I’d be interested to hear how you approached it.

StableJSON: A Practical Workspace for Serious JSON Work

Debjit Dey — Wed, 31 Dec 2025 06:14:37 +0000

JSON is everywhere — APIs, configs, logs, exports, payloads, diffs.
If you build software, you already spend a non-trivial part of your life working with it.

Most JSON tools fall into two camps:

Too basic — format and validate, then you’re on your own
Overengineered — cluttered UIs, half-useful features, slow workflows

StableJSON sits in between.
It’s a focused workspace for actually working with JSON, not just prettifying it.

Live app: https://stablejson.vercel.app
Repo: https://github.com/debjit450/stablejson

Formatting Isn’t the Hard Part

Pretty-printing JSON is solved. Every editor can do that.

The real problems show up when you need to:

Compare large API responses
Debug payload mismatches
Clean data before storage or hashing
Generate types from unknown or evolving structures
Ensure identical data always produces identical output

That’s where things usually break down:

Key order changes
Nulls and empty values add noise
Diffs become unreadable
Hashes change unexpectedly
Generated types drift from reality

StableJSON is built specifically around these failure points.

What StableJSON Actually Gives You

StableJSON is a browser-based JSON workspace with tools that cover the entire JSON workflow:

Validate & format JSON with proper indentation
Clean null, undefined, and empty values in one step
Side-by-side JSON diff with clear highlighted changes
Path inspection & extraction for deeply nested data
Automatic TypeScript interface and Zod schema generation
Canonical JSON output for consistent hashing and comparison
JSONPath queries to slice complex objects
Structure analysis (depth, size, data types)
Transform, flatten, and reshape JSON safely
Custom validation rules when default checks aren’t enough

It’s not a collection of random utilities — it’s one coherent workflow.

Canonical JSON Is the Quiet Power Feature

One of the most important features in StableJSON is canonical output.

When JSON is deterministic:

Hashes stop changing randomly
Cache keys become reliable
Diffs stay readable
CI checks stop failing for no apparent reason

If you’ve ever had two JSON objects that look identical but serialize differently, you already know why this matters.

Canonical output isn’t flashy — but it prevents entire classes of bugs.

Who This Is Built For

StableJSON is for developers who:

Debug APIs regularly
Care about correctness, not just visuals
Work with large or dynamic JSON structures
Need reliable diffs, hashes, and generated types
Want one tool instead of five scattered ones

If JSON is part of your daily workflow, this tool earns its keep very quickly.

Closing

Most JSON tools stop at “looks nice”.

StableJSON goes further — it helps you understand, compare, clean, and stabilize your data.

When you need JSON to be right, not just readable, this is the tool you reach for.

Try it: https://stablejson.vercel.app
Explore the code: https://github.com/debjit450/stablejson

Forem: Debjit Dey

Adaptive Rate Limiting with Redis and Lua

Making Rate Limiting Correct Under Concurrency

The In-Memory Trap

Redis Fixes Distribution, Not Concurrency

The Real Problem: Atomicity

The Fix: Lua Scripts in Redis

Where Algorithms Fit In

Static Limits Miss Real Traffic Behavior

Adding a Behavior Layer

Tradeoffs

Key Takeaway

Closing

StableJSON: A Practical Workspace for Serious JSON Work

Formatting Isn’t the Hard Part

What StableJSON Actually Gives You

Canonical JSON Is the Quiet Power Feature

Who This Is Built For

Closing