DEV Community: Aman Kr Pandey

429: TOO MANY REQUESTS

Aman Kr Pandey — Thu, 05 Mar 2026 18:28:28 +0000

As systems continue to scale to serve millions of concurrent users, the need for controlled and predictable API access has never been more critical. Rate limiting is a traffic management technique that restricts the number of requests a client can make to a server within a defined time period. It serves as a foundational safeguard for system reliability, fairness, and security in production environments.

The Case for Rate Limiting

An API without rate limiting is vulnerable. The consequences of unbounded request traffic can range from low performing micro-services to complete service outages. The primary motivations for implementing rate limiting include:

Protection against denial-of-service (DoS) attacks : Malicious actors can flood endpoints with requests, exhausting server resources and crashing the system.
Prevention of resource monopolization : A single client/user can degrade the experience for all other users
Cost management : Uncontrolled traffic directly affects the cost of the infrastructure used to deploy the application.
Enforcement of API usage plans : Rate limiting enables business models built around different service plans (e.g., free vs. premium plans) to increase frequency of requests in a given time period.

Rate Limiting Algorithms

Several well established algorithms exist for implementing rate limiting, each with distinct trade-offs in terms of accuracy, memory usage, and burst tolerance.

Token Bucket

Now, imagine a bucket of fixed size in which water is flowing at constant rate and for each request you take out one glass of water out of it. If you have sufficient water in the bucket to fill the glass - you accept the request, else rate limit it.

Now, in the bucket replace water with tokens, and each request consumes one token. If the bucket is empty, the request is rate limited and if bucket is full, tokens are dropped/overflown.

To implement this algorithm we require two parameters:

capacity: size of bucket or the maximum number of tokens the bucket should hold at a time.
refillRate: the rate at which tokens are refilled in the bucket.

It is usually better to have different bucket for different API endpoints. Key users of this algorithm include Amazon AWS (API Gateway), Stripe, OpenAI, Cloudflare, and Netflix (Zuul/Envoy).

Leaky Bucket

Now, we have the same bucket again, but instead of taking out a glass of water every time we make a hole at bottom, from where the water leaks out at constant rate (i.e. the request to be processed). Question should be if request is leaking out, what is going into the bucket, tokens or request? In this case request. In this algorithm, whenever a new request arrives we add a glass of water to bucket, and then the water leaks out of the hole at constant rate. What if the bucket is full? The water overflows and the request is dropped.

To implement this algorithm we require two parameters:

capacity: size of bucket or the maximum number of request the bucket should hold at a time.
outFlowRate: the rate at which requests are leaking/processed out of the bucket.

Shopify, Uber and NGINX are known to use leaking bucket algorithm in their APIs.

Fixed Window Counter

The Fixed Window Counter algorithm divides time into fixed, different intervals called windows and tracks how many requests arrive within each one. Every window has a counter starting at zero. Each incoming request increments it, and if the counter exceeds the configured limit, the request is rejected until the next window begins and the counter resets.

To implement this algorithm we require two parameters:

counter: configured limit of count of request
timeWindow: the interval of each window

This algorithm is resource efficient and easy to understand. The only issue with this algorithm is that a bust of traffic at the edges of window, it allows more requests than allowed quota.

Sliding Window

As discussed, fixed window algorithms has a major issue, i.e. more no of requests at the edges of window. We use sliding window algorithm to overcome this hurdle.

There are actually two distinct algorithms under the "sliding window" umbrella:

The Sliding Window Log stores a timestamp for every request and checks how many fall within the rolling window, it is accurate but memory in-efficient at scale.
The Sliding Window Counter, covered in depth below, is the production-grade choice for most APIs.

The Sliding Window Counter is a hybrid approach, it combines the memory efficiency of fixed windows with the accuracy of true sliding windows. Instead of storing individual timestamps, it maintains just two counters: one for the current window and one for the previous window.

When a request arrives, the algorithm estimates how many requests have been made in the "rolling" window using a weighted average:

\text{estimatedCount} = \left(\text{prevCount} \times (1 - \text{windowProgress})\right) + \text{currCount}

Where windowProgress is how far you are into the current time window (a value between 0 and 1).

While being a resource efficient and distributed system ready algorithm (with redis integration to store timestamps and counter), it has certain drawbacks also. It assumes uniform request distribution in the previous window, which may not always hold true. In edge cases, a few extra requests may slip through due to the estimation

Comparison: All Major Algorithms

Algorithm	Memory	Burst Handling	Accuracy	Complexity
Fixed Window	O(1)	Poor (boundary burst)	Low	Low
Sliding Window Log	O(n)	Excellent	Exact	Medium
Sliding Window Counter	O(1)	Good	~Approximate	Medium
Token Bucket	O(1)	Good (controlled)	Good	Medium
Leaky Bucket	O(1)	Excellent (smoothed)	Good	Medium

Conclusion

There is no "best" rate limiting algorithm, we should always select the right algorithm based on requirement. For most distributed, high-traffic APIs, the Sliding Window Counter is the best suited: O(1) memory, redis-friendly, and good performance to boundary bursts. When accuracy is non-negotiable, upgrade to Sliding Window Log. When bursty-but-bounded traffic is the normal in your APIs, Token Bucket performs best. Understanding these trade-offs is what separates a system that survives traffic spikes from one that crashes under it. Check out the implementation of these algorithms here

Thanks for reading, stay tuned!

A solid explanation to SOLID Principle

Aman Kr Pandey — Wed, 31 Dec 2025 12:03:20 +0000

A piece of software rarely fails because the "the algorithm was wrong". It mostly fails slowly because features become hard to add, bugs reappear and even a small change feels risky. SOLID principles give a five very useful practical ways to write code so that it remains understandable and and can adapt to new changes for a significantly longer period of time.

What is SOLID?

It's definitely not one among the three states of matter. SOLID here stands as acronym of 5 design principle that help us write highly maintainable code. The principles are as follows:

Single responsibility Principle
Open-Close Principle
Liskov's Substitution Principle
Interface Segregation Principle
Dependency Injection Principle Together, they encourage loose coupling, clear responsibilities, and stable abstractions, which are essential for long-lived code.

Single Responsibility Principle

Single Responsibility Principle (SRP) states that a class should have one and only one reason to change. Let's say for example we are implementing a class to manage library. An example of bad code that does not follow SRP would be:

This class has four reasons to change:
1.Change in validation logic for user data
2.Change in email templates or email api/client
3.Change in log format
4.Change in DB schema will change the query inside saveToDatabase method

Apart from these it UserService class will be hard to reuse as no one will want to trigger email, and save to database operation when validating user data. This kind of classes are also a testing nightmare as you will have to mock logger, email and db clients.

Better idea would be to have separate class for each one of them.
Below is the example of good code that follows SRP, with each responsibility handled with separate classes.

In the above code each class has only one reason to change and each class is independent of each other, so anyone can use login to validate user or sending email separately, with this email and logging logic can be used in different parts of the code.

So our first mantra to achieve good design is Ek class Ek Kaam.

Open/Close Principle

Open/Close Principle(OCP) states that classes should be open for extension but closed for modification. This principle encourages us to use abstraction instead of concrete class so when we need new behaviors we can add new class instead of modifying the existing behavior of the tested code. This reduces risk while adding new features as you are not modifying the already tested code.

Let's understand OCP via shapes to find the area. The below code calculates the area of the shapes like rectangle and circle.

Let's say if you need to add a new shape, for example a square, if will change the implementation of calculateArea in AreaCalculator class and this is a violation of OCP.

Now a good code that does not violate OCP for the same feature would be as follows.

Here we have created an abstract class Shape that has a abstract method area. This method is overridden in different shape classes like Rectangle. The AreaCalculator class only knows that is is receiving a Shape and it has to call area method on it without worrying about the implementation of area of each shape. In this design it will be easier to introduce new shape like Square with changing implementation of any other class.

So, in order to keep this principle in mind remember the mantra - Extend karo, edit nahi.

Liskov's Substitution Principle

Liskov's substitution principle (LSP) suggestes that a child class can substitute a parent class without changing the correctness or expected behavior of the code. The core idea is, if S is a child class of T, then any piece of code that works with T as object should always work with S as object with out breaking the code or changing the behavior of the code.

Let's understand this with this simple example. Suppose you are making a bird game with different birds that can fly or walk and the following code controls these behaviors

Bird contract promises fly() works for any bird, but Ostrich breaks this promise by throwing an exception. Clients cannot safely substitute Ostrich for Bird and Ostrich's fly() changes the behavior of the code.

Now, we know that all birds can walk but all birds can not fly. So why not have multiple abstraction for each behavior and then a Bird class implementing only the common behavior, like something explained below.

In this code makeWalk() method expects a super-type Bird but sub-classes like Ostrich and Sparrow can substitute it without changing the behavior walk() in respective classes.

In order to remember this easily keep in mind Agar bache ka behavior parents ke jaise hai to wo party me ja sakta hai.

Interface Segregation Principle

The Interface Segregation Principle (ISP), part of the SOLID design principles, states that clients should not be forced to implement interfaces/method they do not use. Instead of large, general-purpose interfaces, we should create smaller, specific ones according to client. This approach reduces tight coupling and makes systems easier to maintain.

In the above code, a single IWorker interface requires all clients to provide eat(), even robots that only work. This violates ISP, creating dummy methods and tight coupling.

A goof practice would be to have separate interfaces Workable and Eatable, and client can implement any combination of the interface as per their requirement. So we refactor the above code to follow ISP.

This reduces coupling and supports extensibility, like adding Rechargeable for robots.

To easily remember this keep in min Divide and Rule: Divide the interface and rule the SOLID principle!

Dependency Injection Principle

This is one of my favourite and most widely used principle, the Dependency Injection Principle (DIP). DIP states that high-level components should not depend on low-level components, both should depend on abstractions. Let's understand with an example.
Let's you are writing a code for making Tea. You can have different types of Tea: Masala Tea, Ginger Tea, Gold tea etc. A simple code to do this would be as follows.

class MasalaTeaMaker {
    public String makeTea() {
        return "Masala Tea ready!";
    }
}

class TeaShop {
    private MasalaTeaMaker maker = new MasalaTeaMaker();  // Hardcoded dependency!

    public String orderTea(String type) {
        if ("masala".equals(type)) {
            return maker.makeTea();
        }
        return "Only Masala available";  // Rigid!
    }
}

The problem here is tight coupling of MasalaTeaMaker with TeaShop, and adding new type of TeaMaker would be risky as it would need us to update TeaShop class, for example if we add GingerTeaMaker also in the code

class MasalaTeaMaker {
    public String makeTea() {
        return "Masala Tea ready!";
    }
}

class GingerTeaMaker {
    public String makeTea() {
        return "Ginger Tea ready!";
    }
}

class TeaShop {
    private MasalaTeaMaker masalaTeaMaker = new MasalaTeaMaker();
    private GingerTeaMaker gingerTeaMaker = new GingerTeaMaker();

    public String orderTea(String type) {
        if ("masala".equals(type)) {
            return masalaTeaMaker.makeTea();
        }else if("ginger".equals(type)){
          return gingerTeaMaker.makeTea();
        }
        return "Un-supported tea type"; 
    }
}

Now, TeaShop is high level which should depend on TeaMaker via abstraction and not through concrete class. So we will no refactor this code and create an interface TeaMaker.

TeaMaker interface lets GingerTeaMaker, GoldTeaMaker implement it. TeaShop depends on abstraction via injection. In the above code injection is done through a constructor, but injections can also be done via setter methods if needed.

As a memory map you can remember Abstraction pe depend karo class pe nahi.

With this we have completed SOLID Principles, for any queries feel free to use comments.

Thanks for reading, stay tuned!

Lazy Heap: Lazy Deletion

Aman Kr Pandey — Mon, 29 Dec 2025 15:03:35 +0000

A lazy heap is a heap-based priority queue that delays some operation on heaps like deletions, merges, or structural cleanup, to future operations in order to simplify implementation or avoid time limit exceeded. This “do it later” strategy comes at the cost of slightly worse worst-case bounds or extra memory for simpler code and often faster execution in practice.

What is Lazy heap?

A lazy heap is a heap variant where certain operations are postponed until it is absolutely necessary. Instead of eagerly fixing the heap after every update, a lazy heap records pending changes and executes them up only when they affect operations like top or pop.

Common types of laziness includes:

Lazy deletion: Mark elements as deleted and physically remove them only when they reach the top of the heap.
Lazy merging: Splice two heap root lists together in O(1) and consolidate later, as in lazy binomial or Fibonacci heaps.
Lazy consolidation: Avoid tree-linking in multi-tree heaps until an extract-min forces cleanup

Here we will cover most frequently used lazy technique, i.e. Lazy deletion with the help of java's PriorityQueue.

public class LazyHeap<T>{
    private int size;
    private PriorityQueue<T> heap;
    private Map<T, Integer> removed;

    public LazyHeap(){
        heap = new PriorityQueue<T>();
        removed = new HashMap<>();
        size = 0;
    }

    public LazyHeap(Comparator<T> c){
        heap = new PriorityQueue<>(c);
        removed = new HashMap<>();
        size = 0;
    }

    public int size(){return size;}
    public T poll(){
        T obj=peek();
        remove(obj);
        return obj;
    }
    public T peek(){
        while(removed.getOrDefault(heap.peek(),0)>0){
            T r=heap.poll();
            removed.put(r,removed.get(r)-1);
        }
        return heap.peek();
    }
    public void add(T obj){
        size++;
        heap.add(obj);
    }
    public void remove(T obj){
        size--;
        removed.put(obj,removed.getOrDefault(obj,0)+1);
    }
}

The class maintains three key fields:

PriorityQueue<T> heap: Standard min-heap storing all elements (live + marked-deleted).
Map<T, Integer> removed: Tracks removal counts for each element using getOrDefault(num, 0) + 1.
int size: Logical count of live elements (increases on add, decreases on remove).

Key Operations

add(T obj)

public void add(T obj){
    size++;  // Logical size increases
    heap.add(obj);  // Push to heap
}

Simply adds to both logical size and physical heap in O(logn) time. No validation is done here, just simple add to heap.

remove(T obj)

public void remove(T obj){
    size--;  // Logical size decreases immediately
    removed.put(obj, removed.getOrDefault(obj,0)+1);  // Mark as deleted
}

The remove() method updates counters in O(1) expected time (HashMap) without touching the heap structure. Multiple calls to remove the same element are handled by the counter, where as a real deletion in heap structure would have costed us O(logn) time.

peek()

public T peek(){
    while(removed.getOrDefault(heap.peek(),0)>0){  // While top is marked deleted
        T r=heap.poll();  // Physically remove it
        removed.put(r, removed.get(r)-1);  // Decrease counter
    }
    return heap.peek();  // Now top is real top of the heap
}

The cleanup in heap structure happens here, where all delete elements are removed from heap. Repeatedly pops already marked as removed top elements until finding a real top element that is not marked as removed. The overall time low if deletions don't cluster at the top.

poll()

public T obj=peek();  // Triggers cleanup, gets live minimum
remove(obj);  // Marks it as deleted (logical removal)
return obj;

This method combines peek() cleanup with logical removal of the top element.

Sample problems to practice

Thanks for reading, stay tuned!

All about Gradient Descent

Aman Kr Pandey — Sat, 27 Sep 2025 06:11:39 +0000

Linear regression is an important algorithms in machine learning. It models the relationship between a dependent variable (target) and one or more independent variables (features) by fitting a linear equation (for example a line) to observed data. This blog will walk through the mathematics behind linear regression models.

What is Linear Regression?

Linear regression finds a linear function that best predicts the target variable y based on predictor variables x. The model equation is:

m_0 + m_1 x_1 + m_2 x_2 + \ldots + m_n x_n

where

m_0

is the intercept and

m1,m2,…,mnm_1, m_2, \ldots, m_n

are the coefficients (weights) for features

x1,x2,…,xnx_1, x_2, \ldots, x_n

. In linear regression we aim to find optimal value for

m0,m1,m2,…,mnm_0, m_1, m_2, \ldots, m_n

to converge the cost function.

But, What is Cost function?

The cost function in linear regression is a mathematical measure of how well the model's predicted values match the actual target values in the training data. It quantifies the difference (error) between the predicted values $(y^)(\hat{y})$ and the true values $(y)$ , representing this error as a single number that the learning algorithm tries to minimize. Now, how does learning algorithm minimizes it? The answer is using Gradient descent.

Gradient Descent

Gradient descent is used to find the global minima of the cost function, lower the cost better the model fits into the data set. But, how it finds the global minima? Remember functions, differentiation, partial derivatives etc. ? We use these mathematical concepts to achieve global minima. Lets understand the mathematics behind it.

Let's consider a simple cost function, a parabolic function $y\ =\ x^{2\ }-4x\ -\ 3$

Now from the graph it is clearly visible that at $x = 2, y = - 7$ , we have the global minima. But, it is not possible to trace graph and observe the global minima for all cost functions because cost functions can be as complex as Mean squared error function with y depending on not just x but multiple independent set of variable like $x0,x1,x2,…,xnx_0, x_1, x_2, \ldots, x_n$ . For example,

J(y^)=12N∑i=1N(y^i−yi)2 J(\hat{y}) = \frac{1}{2N} \sum_{i=1}^{N} (\hat{y}_i - y_i)^2

where, the predicted values is $(yi^)(\hat{y_i})$ , the true values is $y_i)$ , $J(y_i)$ is the cost function, $N$ is number of data points and n is no of feature in each data point. You see, it is very difficult to plot this cost function and observe the local minima, now here comes mathematics to rescue us.

In gradient descent, the core idea is to move in the direction of steepest slope based on calculus (gradient at a point or the slope). So, by walking down the hill step by step we will reach the global minima. Now, how do we find this mathematically. So lets take example of Mean Squared Error (MSE) function, our cost function for linear regression,

J(y^)=12N∑i=1N(y^i−yi)2 J(\hat{y}) = \frac{1}{2N} \sum_{i=1}^{N} (\hat{y}_i - y_i)^2

for regression line $y = m x + b$ , our goal here is to find optimal values of m (slope) and b (intercept) to reduce the cost function. So lets take partial derivative of $J (m, b)$ . So, substituting $y_i = mx_i + b$ and taking partial derivative with respect to m, we get,

\frac{\partial J(m,b)}{\partial m} = \frac{1}{N} \sum_{i=1}^N (x_i((mx_i+b) - y_i))

again, taking partial derivative of

J (m, b)

with respect to b, we get,

\frac{\partial J(m,b)}{\partial b} = \frac{1}{N} \sum_{i=1}^N ((mx_i+b) - y_i)

Let

mcurrm_{\text{curr}}

and

bcurrb_{\text{curr}}

be current values of slope and intercept and

α\alpha

be the rate of learning, then out new slope and intercept will be,

m_{\text{new}} = m_{\text{curr}} - \alpha.\frac{\partial J(m,b)}{\partial m}

b_{\text{new}} = b_{\text{curr}} - \alpha.\frac{\partial J(m,b)}{\partial b}

We keep iterating over this process till our cost function converges, and once the cost function converges we get our optimal value for slope (m) and intercept (b).

Now, this was just to fit a simple straight line containing one variable $x$ , what is we have n number of variables? well in that case we make use of linear algebra with multi-variate calculus.

The General Case

In real life you will not get data whose outcome will depend on a single parameter. In real life, we will have n number of independent parameters on which out outcome would depend. So, how to express these in terms of mathematical equation? Here comes linear algebra and vectors. So, lets say for our regression line $y = m x + b$ , we will try to express each terms in form of matrix for example,

\begin{bmatrix} x \newline 1 \end{bmatrix} , \space M = \begin{bmatrix} m & b \end{bmatrix}

and Y being our outcome matrix, we can now express our line as a dot product of two matrix,

\centerdot X \quad \dashleftarrow (Eq. 1)

Expanding out idea further we can now express a multi-vatiate regression line

m_0 + m_1 x_1 + m_2 x_2 + \ldots + m_n x_n

as,

\begin{bmatrix} 1 \newline x_1 \newline x_2 \newline \cdot \newline \cdot \newline \cdot \newline x_{\text{n-1}} \newline x_n \end{bmatrix} , \space M = \begin{bmatrix} m_0 & m_1 & \cdot & \cdot & m_{\text{n-1}} & m_n \end{bmatrix}

and to express our line, we can take dot product of M and X same as Eq.1 mentioned above. Now lets try to express all our calculation in terms of matrix.

\nabla_M J(M) = \frac{1}{N} \sum_{i=1}^{N} {X_i}^T(M \centerdot X_i - Y_i)

where, $∇MJ(M)\nabla_M J(M)$ is Jacobian expression for $∂J(m,b)∂m\frac{\partial J(m,b)}{\partial m}$ and $∂J(m,b)∂b\frac{\partial J(m,b)}{\partial b}$ . Similarly our new M would be

M_{\text{new}} = M_{\text{old}} - \alpha\nabla_M J(M)

We keep iterating over this process till our cost function converges, and once the cost function converges we get our optimal value for M.

So, this is it, we have covered the mathematics behind gradient descent and how to apply it in optimizing the cost function of models. We will further discuss its implementation using python, till then take care!

Scalable Load Balancing with Consistent Hashing

Aman Kr Pandey — Sun, 27 Jul 2025 17:45:27 +0000

In the world of micro-services, load balancing is a cornerstone to achieve scalability. There are various load balancing algorithms that distributes incoming traffic to multiple servers. This prevents a single server from becoming a bottleneck and ensuring quick response time and less outage. Among multiple load balancing algorithms consistent hashing is an powerful technique of load balancing

Traditional Load balancing algorithms

Imagine a simple scenario with three servers (A, B, C) and a traditional load balancer using a round-robin or modulo-based approach. When a request comes, it is directed to a server based on a simple algorithm. This works fine until you need to add a new server (D), remove an existing one or a server crashes down due to some technical issue.

With traditional methods, adding or removing a server often needs a complete remapping of requests. This can lead to:

Cache Invalidation: If your servers cache data, a remapping means a large portion of your cache becomes invalid, leading to a surge of requests to the backend database as server did not find any cache for remapped request. So, Many requests simultaneously hitting the database can overwhelm it.
Downtime/Low performance: The remapping process can introduce latency or even brief periods of unavailability.

These issues become amplified in microservices architectures and cloud environments where services are constantly being scaled up and down.

Hello! Consistent hashing

Consistent Hashing is a special kind of hashing that minimizes the impact of adding or removing a server on the overall distribution of request over hash of servers. Instead of remapping every request only a small fraction of requests are affected.

How it works

Think of a a ring, that represents your hash space for servers and requests. Both server and requests are mapped to the hash ring using a hash function.

Server Placement: Our first task is to place the servers on the hash ring. Each server is hashed using a hash algorithm and placed on the specific position on the ring
Placement of requests: For incoming requests too we hash them and place them on the ring. Request and server may/may not point to same position on the ring.
Server assignment: Once both server and request is mapped to the ring, each request gets the next available server on the ring, your direction or traversal may be clockwise or anticlockwise. The first server we encounter while traversing that server gets allocated to the request.

Lets take reference to above image, it has a ring with hash space of n = 100 and four servers (A,B,C,D), number within them represent the index/hash where are located on the ring and we are traversing in clockwise direction on the ring.

So, if any incoming request with hash 10 will be allocated to just next server in clockwise direction, in this case its Server B.

Note: Hash space should be large enough to avoid collision based on your hashing algorithm.

How this makes the difference

Now, let us see what happens when we add or remove a server:

Adding a Server: When a new server is added to the ring, it only takes over a portion of the requests from its neighbour. The vast majority of other requests remain mapped to their original servers. For example, if we add a Server E which has value 40 between Server B and Server C. Only requests of value greater that hash value 20 and less that equal to 40 will be remapped to Server E, rest all mapping will remain same.
Removing a Server: When a server is removed, its requests are simply re-mapped to next clockwise neighbour. Again, only a localized change occurs. Again, if we remove Server E all the request getting assigned to E will automatically get re-mapped to Server C.

This localized remapping is the core benefit of Consistent Hashing.

Benefits for Load Balancing:

Reduced re-mapping: This reduces the number of requests that need to be re-mapped when servers are added or removed.
Improved Cache Utilization: Preserves a significant amount of cached data, reducing the load on backend systems.
Enhanced Scalability: Allows for seamless scaling up and down of server capacity without significant performance issues.
Reduced Thundering Herd: Prevents a sudden surge of requests to the database.
Better Availability: Contributes to more stable and available systems during scaling events.

Drawbacks of Consistent Hashing

Uneven distribution: With the distribution of requests on the ring may not be even, it may happen that a server in ring gets most of the requests and other does not get any traffic at all. To mitigate this we use virtual nodes. Instead of mapping physical server directly on the ring we map multiple virtual nodes on the ring that point to the same physical. This helps a single physical server to appear at multiple places on the ring, and thus avoid uneven distribution of requests. The quality of hash function used also has a significant affect on distribution.
Performance overhead: Repeated hashing of requests and traversing the ring even with using best data structures and optimised algorithms may introduce slight performance overhead as compared to simple hashing techniques.
Cold start issue: When a new server is added to the ring, it is likely to have an empty cache for that hash in the backend, so this may increase load on backend databases/cache for quite some time.

Implementation of Consistent Hashing

While the concept is straightforward, implementing a robust Consistent Hashing solution often involves libraries or frameworks that handle the complexities of managing the hash ring, virtual nodes, and server discovery, but for better understanding we will implement a simple consistent hash scheduler.

Create a class in java ConsistantHashScheduler

public class ConsistantHashScheduler{
    private static final Logger logger = LogManager.getLogger(ConsistantHashScheduler.class);

    private ArrayList<Server> nodes;
    private ArrayList<Integer> keys;
    private ArrayList<Server> servers;
    private int maxPoolSize;

    public ConsistantHashScheduler(ArrayList<Server> servers, int maxPoolSize) {
            logger.info("Initializion a consistent hash scheduler with pool size: {}",maxPoolSize);
        this.maxPoolSize = maxPoolSize;
        this.servers = servers;
            this.keys = new ArrayList<>();
        this.nodes = new ArrayList<>();
    }
}

Add hash function of your choice

private int getHash(String ip) throws NoSuchAlgorithmException {
        MessageDigest digest = MessageDigest.getInstance("SHA-256");
            byte[] hashBytes = digest.digest(ip.getBytes(StandardCharsets.UTF_8));

            int hash = 0;
            for (int i = 0; i < 4; i++) {
                hash <<= 8;
                hash |= (hashBytes[i] & 0xFF);
            }
            return (hash & Integer.MAX_VALUE) % this.maxPoolSize;
    }

This method hashes an IP using SHA-256, extracts a 32-bit integer, and scales it for pool size, ensuring even distribution.

Now, implement addServer method.

public void addServer(Server server) throws Exception {
        if(keys.size() == this.maxPoolSize) {
            throw new Exception("Max server pool size overflow");
        }

        logger.info("adding new server: {}",server.toString());

        int key = this.getHash(server.getUrl());
        int index = Collections.binarySearch(this.keys, key);



        if(index > 0 && this.keys.get(index) == key) {
            throw new Exception("Collosion occured for server "+ server.toString());
        }

        int insertionPoint = -(index+1);

        this.keys.add(insertionPoint,key);
        this.nodes.add(insertionPoint,server);

        return;
    }

This addServer method adds a new server to a Consistent Hashing ring. It calculates the hash of server, finds its insertion point in a sorted list of keys to maintain the ring order, and then inserts both the hash and the server. It handles pool size limits and hash collisions.

Add removeServer method.

public void removeServer(Server server) throws Exception {

        if(this.keys.size() == 0) {
            throw new Exception("No nodes in the server pool");
        }

        int key = this.getHash(server.getUrl());

        int index = Collections.binarySearch(this.keys, key);

        if(index < 0) {
            throw new Exception("Unknown server, not present in nodes");
        }

        this.keys.remove(index);
        this.nodes.remove(index);

        return;

    }

This removeServer function deletes a server from the Consistent Hashing ring. It hashes the URL of server, finds its position via binary search, and removes its key and the server object from the sorted lists. It validates against an empty pool or unknown servers.

Let's schedule some requests.

public Server schedule(HttpExchange exchange) throws NoSuchAlgorithmException {
        int key = this.getHash(exchange.getRemoteAddress().getHostName());
        int index = Collections.binarySearch(keys, key);

        int nodePoint;

        if(index >= 0) {
            nodePoint = index;
        }else {
            nodePoint = ((-(index+1))%this.keys.size());
        }
        return this.servers.get(nodePoint);

    }

This schedule method is core logic of a load balancer. It hashes the incoming request's client IP, then uses binary search on the sorted hash ring (keys) to find the appropriate server. If no exact match, it calculates the next clockwise server using modulo, returning the chosen Server object.

The summary of the above implementation can be found here.

At last

Consistent Hashing offers an efficient approach to load balancing. By minimising the impact of frequent changes, it ensures greater stability and availability, allowing the systems to scale better. If you are building or optimizing a distributed system, understanding and implementing Consistent Hashing is an important tool in your skill set.

PKCE Demystified: How OAuth 2.0 Became More Secure for Public Clients

Aman Kr Pandey — Mon, 23 Jun 2025 13:18:57 +0000

OAuth2.0 has been a very popular protocol among developers for delegating authorization for modern apps. But when it comes to mobile apps or single page application (SPAs), the traditional Authorization code flow done with the help of client_id and client_secret has a serious security vulnerability: Code Interception.

Here enters: PKCE (Proof Key for Code Exchange) — a security enhancement that protects public clients from code interception attacks. This post breaks down what PKCE is, how it works, and how to implement it.

Need of PKCE Flow

In the traditional OAuth2.0 Authorization code flow, the client first sends authorize request to authorization server with client_id, the server then responds back with a authorization_code and then the client sends a request with the authorization_code and client_secret. Now, the problem here is that public client like mobile apps and SPAs can not store secrets securely and this makes them vulnerable to interception attacks. So, your authorization_code and client_secret once they get intercepted by an attacker can use them to initiate token exchange and access resources. PKCE flow mitigates this by adding a dynamic challenge and verification in each authorization request. This ensures that only the app has the ability to get authorized not any attacker even if they have intercepted the authorization_code.

How PKCE Flow works

Let's walk through the PKCE flow and how it works:

1. Client generates Secret and Challenge

In this steps the client create a Secret and a Challenge. Secret is any random string and the Challenge is hashed version of the Secret using any of the cryptographic algorithms (SHA3-256 in our case).

code_verifier = randomString(43-128 chars) 
code_challenge = base64url(SHA3-256(code_verifier))

2. Client send authorize request with `code_challange`.

The client initiates authorization.

GET /authorize?
  response_type=code&
  client_id=your-client-id&
  redirect_uri=https://yourapp.com/callback&
  code_challenge=f591f035a31f320015177cadb73e2056939b5ddbd30e902c5f274bc092b29545&
  code_challenge_method=SHA3-256

So there are two methods to pass code_challange_method. First we can save it in the database of our authorization server as part of client's config, secondly we can pass it in the URL as a parameter, to add an extra layer of security in second method we can keep changing the method in each request.

3. User approval and server's redirect

The user logs in and approves apps access to its resources, and the authorization server redirects to client's callback url with authorization_code.

Once the user is authenticated the server stores the code_challenge and code_challenge_method against authorization_code that it issued.

4. Client initiates token exchange

Now once redirected, the client then uses authorization_code to get tokens in exchange. Here the client sends code_secret as parameter in request. This is the original Secret generated in the first step.

POST /token
Content-Type: application/x-www-form-urlencoded

grant_type=authorization_code&
code=XYZ&
code_secret=some_code

The server compares the hash of code_secret with the earlier code_challenge. If they match, it issues tokens. Here while generating the hash from code_secret one may introduce hash rounds a client's config, which is stored over database and only known to authorization server and the client. Adding hash rounds makes apps more secure and even less vulnerable to attacks. Even if someone mimics the PKCE flow, creating their own secret and challenge, they might not be aware of exact number of hash rounds.

When to use PKCE?

Use PKCE whenever your app is a public client:

Native mobile apps (iOS, Android)
Single Page Applications (React, Angular, Vue)
Desktop apps (Electron, etc.)

Implementation Tips

Use SHA-256 as cryptographic method, or keep changing for each request
Never re-use code_secret, always generate new Secret for new request
Keep the PKCE logic in secure memory, avoid writing to local storage in browsers

Conclusion

So, at last we can conclude that OAuth2.0 can be a great choice to authorize users if you are building a public client, but with PKCE it adds more security with minimal complexity.

Thanks for you time!
Have a great day ahead!

DEV Community: Aman Kr Pandey

429: TOO MANY REQUESTS

The Case for Rate Limiting

Rate Limiting Algorithms

Token Bucket

Leaky Bucket

Fixed Window Counter

Sliding Window

Comparison: All Major Algorithms

Conclusion

A solid explanation to SOLID Principle

What is SOLID?

Single Responsibility Principle

Open/Close Principle

Liskov's Substitution Principle

Interface Segregation Principle

Dependency Injection Principle

Lazy Heap: Lazy Deletion

What is Lazy heap?

Key Operations

Sample problems to practice

All about Gradient Descent

What is Linear Regression?

But, What is Cost function?

Gradient Descent

The General Case

Scalable Load Balancing with Consistent Hashing

Traditional Load balancing algorithms

Hello! Consistent hashing

How it works

How this makes the difference

Benefits for Load Balancing:

Drawbacks of Consistent Hashing

Implementation of Consistent Hashing

At last

PKCE Demystified: How OAuth 2.0 Became More Secure for Public Clients

Need of PKCE Flow

How PKCE Flow works

1. Client generates Secret and Challenge

2. Client send authorize request with code_challange.

3. User approval and server's redirect

4. Client initiates token exchange

When to use PKCE?

Implementation Tips

Conclusion

2. Client send authorize request with `code_challange`.