DEV Community: Nilotpal Baishya

Building a Distributed Rate Limiter from Scratch

Nilotpal Baishya — Sat, 11 Jul 2026 11:48:30 +0000

Introduction

There comes a point while learning software engineering where using a technology isn't enough anymore.

For me, that technology was Redis. I had used Redis before in small projects. I knew it was fast, great for caching, and commonly used in backend systems. But there was one thing I couldn't confidently explain:

How do distributed applications actually implement rate limiting?

I understood the concept of rate limiting, but not the engineering behind it. Instead of watching another tutorial, I decided to build one from scratch.

That project eventually became Aegis—my first open-source Python package.

Why Build Another Rate Limiter?

Honestly, I wasn't trying to build a better rate limiter. There are already plenty of mature libraries that solve this problem far better than something I could build alone.

My goal was much simpler. I wanted to understand how these systems actually work under the hood.

That meant asking questions like:

How do different rate limiting algorithms behave?
Why is Redis commonly used?
What causes race conditions?
Why do people use Lua scripts with Redis?
How would I design a library that other developers could actually use?

The only way I knew how to answer those questions was by building everything myself.

Starting Small

Like most projects, Aegis didn't start with Redis or distributed systems. It started with a simple in-memory implementation.

I first implemented four common rate limiting algorithms:

Fixed Window
Sliding Window
Token Bucket
Leaky Bucket

Getting each algorithm working taught me that they all solve the same problem in different ways.

Some are simple. Some are more accurate. Some allow bursts of traffic. Some smooth traffic over time.

Understanding those trade-offs was one of the most interesting parts of the project.

Making It Distributed

Once the in-memory implementation was working, I started thinking about a more realistic scenario.

What happens when your application runs on multiple servers? An in-memory counter only exists inside a single process. If two servers each keep their own counters, the rate limiter isn't really shared anymore.

That's where Redis came in. Redis became the shared source of truth, allowing every application instance to work with the same state.

But moving the logic to Redis introduced another challenge-Race conditions.

Two requests arriving at almost the same time could both read the same value before either one updated it.

To solve that problem, I implemented the Redis algorithms using Lua scripts, allowing the entire operation to execute atomically on the Redis server. It was one of the biggest learning moments during this project.

Beyond the Algorithms

At some point, I realized Aegis was becoming more than just a collection of algorithms. So I spent time improving the architecture.

Some of the things I added were:

A shared Redis Lua base class
Separate Redis and in-memory backends
A simple SDK API
Unit and integration tests
GitHub Actions for automated testing
Black and Ruff for formatting and linting
Packaging and publishing to PyPI

These weren't the most exciting features to build, but they made the project feel much more complete.

What I Learned

Looking back, Aegis taught me much more than rate limiting.

It taught me how to think about distributed systems, software design, testing, packaging, and maintaining an open-source project. More importantly, it reminded me that the best way to understand a complex topic is often to build it yourself.

There are still plenty of things I want to improve, and Aegis is far from finished. But I'm happy with where it has taken me so far.

Final Thoughts

This project started with a simple question:

"How does distributed rate limiting actually work?"

Trying to answer that question led me through Redis, Lua, multiple algorithms, software architecture, testing, CI/CD, and eventually publishing my first open-source Python package.

If you're learning backend engineering, I'd definitely recommend picking a problem that interests you and building it from scratch.

You'll probably learn much more than any tutorial could teach.

If you'd like to check out the project:

⭐ GitHub: https://github.com/Nilotpal04/aegis

📦 PyPI: https://pypi.org/project/aegis-rl/0.1.1/

You can install it with:

pip install aegis-rl

Feedback and suggestions are always welcome!

7 Backend Concepts That Separate a Real Backend from a Simple CRUD Application

Nilotpal Baishya — Fri, 19 Jun 2026 15:59:07 +0000

The moment I first started learning backend development, I already knew that real applications involved much more than CRUD operations. What I didn't fully understand was how these things are actually built behind the scenes.

While building backend projects and reviewing a larger FastAPI codebase, I came across several concepts that repeatedly appear in real-world systems. The interesting part wasn't discovering these concepts—it was understanding why they exist and what problems they solve.

Here are 7 backend concepts that changed how I think about backend engineering.

1. Authentication (JWT)

The first question every backend needs to answer is:

"Who is making this request?"

Without authentication, anyone can access your endpoints and perform actions they shouldn't be able to. While building projects, authentication was one of the first concepts that made my backend feel more like a real application. Instead of allowing every request, users now had to log in, receive a token, and include that token when accessing protected routes.

This is where JWT (JSON Web Tokens) came in.

Implementing login, protected routes, and a /me endpoint helped me understand how applications keep track of users and verify their identity.

2. Authorization (RBAC)

Authentication tells us who the user is and "Authorization" tells us what they are allowed to do.

For example:

A normal user can upload documents.
An admin can verify documents.
Another role might manage users.

As applications grow, managing permissions becomes increasingly important. Initially, it may seem easy to add a few checks wherever needed, but that approach quickly becomes difficult to maintain.

This is where RBAC (Role-Based Access Control) comes in.

Instead of scattering permission checks throughout the codebase, roles can be centralized and enforced through reusable dependencies and helper functions.

Learning RBAC helped me understand how larger applications manage permissions cleanly, while keeping the code organized and easier to maintain.

3. Dependency Injection

This was probably the concept that confused me the most when I started learning FastAPI.

I kept seeing things like:

db: Session = Depends(get_db)

and

current_user: CurrentUser

without fully understanding what was happening behind the scenes.

Eventually, I realized that dependency injection is simply a way of providing things like database sessions, authenticated users, and permissions to endpoints automatically.

Once it clicked, a lot of FastAPI's design started making sense. It also helped me understand how the same database session, current user, or permission checks could be reused across multiple endpoints without repeating the same code everywhere.

4. Global Exception Handling

In smaller projects, it's common to see:

raise HTTPException(...)

everywhere.

That works at first, but as the application grows, error handling can quickly become repetitive and harder to maintain.

While building projects, I learned how custom exceptions and global exception handlers can make this much cleaner.

Instead of repeating the same response logic in every route, the backend can define reusable exceptions such as:

UnauthorizedError
ForbiddenError
ConflictError
NotFoundError

The framework then handles these exceptions consistently across the entire application.

Besides reducing repetition, this approach also makes the code easier to read and helps keep API responses standardized.

5. Audit Logs

This was one concept I hadn't paid much attention to when I started learning backend development.

Imagine an admin verifies a document.

A few days later someone asks:

Who verified it?
When was it verified?
What action was taken?

Without audit logs, there is no answer.

Audit logs create a history of important actions inside the system. They don't directly add new features for users, but they make systems much more reliable and traceable.

After implementing and reviewing them in real projects, I started noticing how important they are in applications where accountability and record-keeping matter.

6. Database Migrations (Alembic)

One thing I quickly realized while working with databases is that changing a model is easy, but safely updating an existing database is not.

What happens when a new column is added? Or a table structure changes after the application is already being used?

This is where Alembic comes in. A simple way to think about it is: Alembic is like Git for your database schema. It keeps track of changes and allows those changes to be applied in a controlled and repeatable way.

Instead of manually modifying the database, migrations provide a structured and controlled way to evolve the schema over time.

Learning Alembic helped me understand that managing a database isn't just about creating tables. It's also about safely handling change as an application grows and new requirements emerge.

7. Asynchronous Programming

One of the most intimidating concepts I encountered was Async. At first, I understood the syntax, but I didn't fully understand when asynchronous programming was useful or what problem it was trying to solve.

What I learned is that asynchronous programming allows a server to handle other work while waiting for certain operations to complete.

This becomes especially useful for:

Database operations
Network requests
File handling
External APIs

One lesson that really stuck with me was that simply writing:

async def my_function():
    await some_async_operation()

does not automatically make a function asynchronous. The code inside the function also needs to perform asynchronous operations for async to provide any real benefit. Understanding that distinction helped me appreciate why async exists and where it actually provides value in backend applications.

Final Thoughts

Before learning these concepts, I mostly focused on getting features to work. If an endpoint returned the correct response, I was happy.

But while building project and reviewing a larger backend, I started realizing that backend development is about much more than making things work.

Questions like:

Who is making this request?
Are they allowed to do this?
What happens if something goes wrong?
How do we track important actions?
How do we safely change the database later?

started becoming just as important as the endpoints themselves.

I'm still learning, and I have a lot more to explore. But understanding concepts like JWT authentication, RBAC, dependency injection, audit logs, Alembic, and async programming has given me a much better picture of how real backend applications are built.

For me, these concepts were the first step from simply building APIs to thinking more like a backend engineer.

My First CORS Error in FastAPI

Nilotpal Baishya — Wed, 03 Jun 2026 10:57:54 +0000

I'm learning FastAPI. And I am not a person who can learn by watching tutorials.

So I decided to learn while building. So I built something small just to start with FastAPI. A basic expense tracker.

Nothing fancy. Just a FastAPI backend with a few endpoints and a simple HTML page with JavaScript. There are three buttons in it: Load Expenses, Add Expense, Calculate Total. I just wanted to see how frontend talks to backend.

Everything seemed fine

I started the server. No errors. Tested my API in Swagger UI. Worked perfectly. Then I opened my HTML file. Clicked "Load Expenses."

But there was nothing. like no expenses, no error, just nothing.

I stared at the screen thinking What did I do wrong?

I blamed my backend first

I thought I messed up my Python code. I checked everything but there was nothing wrong. Then tested Swagger UI again. The endpoint was fine.

Then I blamed my frontend

So I went to check my fetch request. It looked fine to me. I checked the button. Worked fine. But after all this there was still nothing.

Then I opened the browser console

This was the moment. I clicked F12 and saw this red error:

Access to fetch at 'http://127.0.0.1:8000/expenses' from origin 'http://127.0.0.1:3000' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource.

I had no idea what CORS meant.

What I learned

I learnt that my backend was working the whole time. I searched about CORS error and came to know about what is CORS and all. The browser was blocking it. SO my frontend was on port 3000 and my backend was on port 8000.They are different ports. The browser saw them as different "origins" and said "nope, not allowed unless the backend gives permission."
My backend wasn't giving permission. So I added the CORS middleware, it adds special HTTP headers to my backend responses.

The fix

I added this to my FastAPI code:

from fastapi.middleware.cors import CORSMiddleware

app.add_middleware(
    CORSMiddleware,
    allow_origins=["http://127.0.0.1:3000"],
    allow_methods=["*"],
    allow_headers=["*"],
)

What stuck with me

The fix was four lines. But what I actually learned was:

I should always open the browser console FIRST. At least not after checking everything else.
Test my API separately before blaming it.
CORS errors are browser things, not code bugs.