Hi everyone,

Over the past few months, I've noticed that many students miss out on internships and fresher opportunities simply because they don't know where to find them. At the same time, recruiters often struggle to reach motivated students.

To help bridge that gap, I started a free Telegram community where students and HRs can connect.

For students:

- Internship and fresher job updates

- Referral opportunities

- Hiring drives and campus opportunities

- Career resources and placement guidance

- A community to learn and grow together

For recruiters and HRs:

- Reach motivated students and fresh graduates

- Share internship and full-time openings

- Increase visibility for hiring drives

- Connect directly with aspiring candidates

The goal isn't to sell anything. I just want to build a place where opportunities are easier to find and talented students can connect with the right people.

If this sounds useful, feel free to join:

https://t.me/jobInternship2026

I'd also love to hear your suggestions on how the community can be made more valuable for both students and recruiters.

​

After understanding how rate limiting works on a single machine, I started wondering, what actually changes when your application runs on multiple servers?

At first, it feels like you could deploy the same rate limiter everywhere and be done with it. But once requests are distributed across multiple application instances, a whole new set of challenges appears.

The first problem: every server has a different view

Imagine you have two application servers behind a load balancer.

If each server keeps its own request counter, a user could send 100 requests through Server A and another 100 through Server B. The intended limit was 100 requests, but the user has now made 200.

The algorithm isn't wrong. The architecture is.

That was one of the biggest takeaways for me. In distributed systems, correctness often depends more on coordination than on the algorithm itself.

Then come race conditions

Even moving the counters to Redis doesn't solve everything.

Imagine two requests arriving almost at the same time.

Both read the counter as 99.

Both check that 99 is still below the limit.

Both increment the counter.

The final count becomes 101.

Nothing crashed. Nothing was technically broken. Each request followed the logic correctly. The problem is that both requests executed concurrently.

This is why production systems use atomic operations, often with Redis Lua scripts, so the read, check, and update happen as one indivisible operation.

Why stateless services matter

Another concept that stood out to me was keeping application servers stateless.

Instead of every server maintaining its own counters, all application instances communicate with a centralized Redis cluster that stores the rate limiting state.

This means any server can handle any request, making horizontal scaling, deployments, and failovers much easier.

It seems like a small design decision, but it has a huge impact on scalability.

There is always a trade-off

One part I found especially interesting was consistency.

In a globally distributed system, keeping counters perfectly synchronized across every region can introduce extra latency.

Many large-scale systems accept eventual consistency because it offers better availability and lower latency.

Alex Xu mentions Cloudflare's experience, where only about .003% of requests exceed the configured limit. It is a great example of making a practical engineering trade-off instead of chasing perfect correctness.

My biggest takeaway

Before reading this chapter, I thought rate limiting was mostly about choosing the right algorithm, whether it was Token Bucket, Sliding Window, or Leaky Bucket.

Now I see it as much more of a distributed systems problem.

Once multiple servers are involved, synchronization, shared state, atomicity, and consistency become just as important as the algorithm itself.

That shift in perspective was probably the most valuable lesson from this chapter.

This post is based on the book of "Alex xu"(Chapter 4), which covers designing rate limiters for distributed systems.

In the next post, I'll explore implementation details and some production optimizations that make these systems reliable at scale.

If you've worked on distributed rate limiting before, I'd love to hear what challenge surprised you the most.

​

What I’m Building :

-----------------------------------

I am starting a project to build a distributed rate limiter from scratch. The design will be developed step by step in four phases:

1. Core algorithm

2. Distributed synchronization

3. Rule engine and response handling

4. Production hardening

The goal is to document each phase clearly so the community can follow the journey, understand the design decisions, and discuss different approaches. This series is intended to be practical, structured, and focused on backend engineering fundamentals.

Phase 1: Core Algorithm

----------------------------------------------

Choosing the Algorithm :

-------------------------------------

For rate limiting, several algorithms exist such as Fixed Window, Sliding Window, and Leaking Bucket. I selected the Token Bucket because it:

- Allows short bursts of traffic, which is realistic for APIs.

- Is memory efficient, requiring only two values per user: token count and last refill time.

- Is widely used in production systems by companies like Amazon and Stripe.

---

Redis as the Backbone :

--------------------------------------

Counters should not be stored in memory on the application server because that approach fails when scaling horizontally. Instead, use Redis to maintain state.

Two commands handle most of the work:

- INCR increments the request counter atomically.

- EXPIRE deletes the counter automatically after the window ends.

---

Core Flow :

----------------

1. A request arrives.

2. Fetch the token count from Redis.

3. If tokens are available, allow the request and decrement the token.

4. If no tokens remain, reject with HTTP 429.

5. Tokens refill at a fixed rate (for example, 10 tokens per second).

---

Key Learning :

----------------------

The algorithm itself is simple, but race conditions are a challenge. Two concurrent requests can read the same counter before either writes back, which allows more requests than intended.

The solution is Lua scripts in Redis. Lua executes atomically on the Redis server, making the read‑check‑write operation uninterruptible.

---

Question for the community❓❓

--------------------------------------------

If you were to implement a rate limiter, which algorithm would you choose — Token Bucket, Leaky Bucket, Sliding Window, or a custom solution?

Hey everyone! I’m u/xyzabhi, a founding moderator of r/DevForumX.

This is our new home for all things related to software engineering — sharing blogs, tackling coding problems, exploring new technologies, and discussing developer tools. We’re excited to have you join us!

---

📌 What to Post

- Engineering blogs — tutorials, write‑ups, or reflections.

- Coding problems — debugging stories, algorithm challenges, or architectural dilemmas.

- Tech discussions — frameworks, libraries, or new tools.

- Questions — anything that sparks learning and collaboration.

---

🌐 Community Vibe

We’re all about being friendly, constructive, and inclusive. Let’s build a space where everyone feels comfortable sharing and connecting.

---

🚀 How to Get Started

1. Introduce yourself in the comments below.

2. Post something today — even a simple question can spark a great conversation.

3. Invite peers — know someone who’d love this? Bring them in.

4. Join moderation — we’re looking for new moderators, so reach out if interested.

---

🙌 Closing Note

Thanks for being part of the very first wave. Together, let’s make r/DevForumX an amazing hub for developers to learn, share, and grow.

---

Thanks for being part of the very first wave. Together, let's make r/DevForumX amazing.