Forem: Guna Sai

Rate Limiting: Concepts, Algorithms, and Distributed Challenges

Guna Sai — Sun, 08 Feb 2026 11:15:39 +0000

If you've ever built an api or backend service, you've probably faced one of these problems:

One user sends too many requests
bots abusing your endpoints
traffic spikes breaking your service
retries or cron jobs accidentally overloading your system.

This blog is about rate limiting, a simple but critical technique used to protect systems from these issues

In this post, we will

understand why rate limiting is needed,
learn how common rate limiting algorithms work,
see where rate limiting fits in real systems.

You don't need prior knowledge of rate limiting.
If you understand basic APIs and requests, you'll be able to follow along.

Content of this blog

The Problem Rate Limiting Solves
What Rate Limiting Actually Does
Common Rate Limiting Algorithms
- Fixed Window Counter
- Sliding Window
- Token Bucket
- Leaky Bucket
Comparing the Algorithms
Challenges in Distributed Systems

The Problem Rate Limiting Solves

When a req hits your server, it consumes resources like CPU time, memory, database connections, network bandwidth etc...

Under normal usage, this works fine, but problems starts when too many requests arrive at the same time.

This can happen because of:

a single user sending requests in a tight loop,
bots hitting public endpoints,
retry mechanisms without proper backoff,
sudden traffic spikes after a release or promotion

The server sees all requests as the same it doesn't know which request is important and which one is harmful.

Why does this becomes a serious problem

If the request volume keeps increasing without limits:

response times go up,
Databases start slowing down,
timeouts increase,
error rates spike,
and eventually the service becomes unavailable for everyone.

Why can't we just "scale the server."

Our common reaction will be "let's just add more servers."

Scaling helps, but it does not solve the root problem.

eventually, unlimited requests will overwhelm any system,
scaling increases cost,
Databases, third-party APIs may not scale the same way.

if just keep on scaling it only delays failure.

What systems really need is

a way to control how fast requests are allowed.
protection against accidental or intentional abuse,
fairness so one user cannot starve others.

This is exactly the problem rate limiting is designed to solve.

What Rate Limiting Actually Does

At its core, rate limiting controls how frequently an action is allowed within a given time period.

Most commonly, this action is an API request.
A rate limit usually looks like this:

allow 100 reqs per minute per user
allow 10 reqs per second per IP
allow 1 request per second for a sensitive endpoint

When the limit is reached, the system does not process further reqs until enough time has passed.

What happens when a limit is exceeded

When a client crosses the allowed limit:

the request is rejected,
the server responds immediately,
resources are preserved for other users.

In HTTP-based systems, this is commonly returned as a 429 Too Many Requests response.

This early rejection is important.

It prevents unnecessary work from happening in the system, such as database queries or external api calls.

What rate limiting guarantees

Rate limiting helps systems achieve a few important guarantees:

Fair usage

One user cannot consume resources meant for everyone else.
Predictable performance

The system remains responsive even under load.
Controlled bursts

Some algorithms allow short bursts while still enforcing long-term limits.
System protection

Accidental bugs or misbehaving clients are contained early.

What rate limiting does NOT do

Rate limiting is often misunderstood, so it's important to be clear about its limits.

Rate limiting is not:

authentication (it does not verify who the user is),
a complete security solution,
a replacement for proper input validation.

It is a traffic control mechanism, not a security gate.

Common Rate Limiting Algorithms

Different systems use different rate limiting algorithms depending on their needs.
There is not algo that is "best", each one makes different trade-offs
btw simplicity, accuracy, and flexibility.

let's go through the most commonly used ones,

Fixed Window Counter

This is the simplest form of rate limiting.

How it works

Time is divided into fixed windows, such as 1 minute or 1 hour.
For each user, the system keeps a counter for the current window.
Every incoming request increments this counter.
Once the counter reaches the limit, further requests are rejected.
When the window ends, the counter is reset to zero.

Example

Limit: 5 requests per minute
Window: 12:00 - 12:01
A user sends 5 requests at 12:00:59 -> all allowed
The counter resets at 12:01:00 -> another 5 requests are allowed

This means the user effectively made 10 requests in 1 second.

Why Fixed Window fails
The main issue with Fixed Window Counter is that it only looks at the clock.

It does not care how requests are distributed inside the window.

Because of this:

users can exploit window boundaries,
traffic becomes very bursty,
backend services can suddenly receive huge spikes,
the system becomes unfair under load.

When Fixed Window can be acceptable

very low-traffic systems,
internal tools,
prototypes or demos,
cases where correctness is less important than simplicity.

In most production apis, Fixed Window is usually avoided.

Sliding Window

Sliding window algorithms try to fix the burst problem of fixed windows.

Instead of looking at a fixed clock window, the system looks at the last N seconds from the current time.

How it works

The system always looks at the last N seconds from the current time.
Every request is evaluated against this rolling window.
The system counts how many requests occurred in the previous N seconds.
If the count exceeds the limit, the request is rejected.

Example

Limit: 100 requests per 60 seconds
At any moment, the system checks how many requests happened in the previous 60 seconds

This prevents sudden spikes caused by window resets, as reqs are spread more evenly over time.

Sliding Window is better because

much fairer request distribution,
Traffic spikes are naturally reduced
No burst problems at window boundaries.

Sliding Window is harder because

the system need to store timestamps of requests,
memory usage increases with traffic,
more computation is needed per req.

Token Bucket

Token Bucket is one of the most commonly used algorithms in production systems because it balances strict limits with good user experience.

How it works

Each user has a bucket that holds tokens.
Tokens are added to the bucket at a fixed rate.
Each request consumes one token.
If there are no tokens left, the request is rejected.
The bucket has a maximum capacity, so tokens cannot grow infinitely.

Example

Bucket size: 10 tokens
Refill rate: 1 token per second

Scenario:

User is idle -> bucket fills up to 10 tokens
User sends 10 requests instantly -> all allowed
The 11th request is rejected
After 1 second, 1 token is added -> 1 request allowed

Token Bucket works well because

allows short bursts without breaking the system,
enforces long-term rate limits,
provides better user experience,
simple and efficient to implement.

Because of these properties, Token Bucket is often the default choice for APIs.

Leaky Bucket

Leaky Bucket focuses on producing a smooth and stable output rate.

How it works

Incoming requests are placed into a queue (the bucket).
Requests leave the queue at a constant, fixed rate.
If the queue becomes full, new requests are dropped.

Example

Many requests arrive at once
The system processes requests at a steady pace
Extra requests are dropped when the queue is full

Leaky Bucket is useful because

protects downstream systems very well,
ensures predictable processing speed,
prevents sudden traffic spikes.

But Leaky Bucket is not ideal for APIs because

burst requests are delayed or dropped,
latency increases under load,
user experience can suffer.

Leaky Bucket is more suitable for background jobs and pipelines than user-facing APIs.

Comparing the Algorithms

The goal here is not to dive deep again, but to understand which algorithm fits which situation.

High-level Comparison

Algorithm	Burst Handling	Fairness	Complexity	Common Usage
Fixed Window	Poor	Low	Very Low	Simple or low-traffic systems
Sliding Window	Good	High	High	Systems needing accuracy
Token Bucket	Very Good	High	Medium	Most APIs
Leaky Bucket	Poor	Medium	Medium	Background jobs

How to think about the choice

Fixed Window is easy to build, but breaks under bursty traffic. It's fine for simple or internal use cases.
Sliding Window gives fair and accurate limits, but costs more in memory and computation.
Token Bucket is the most practical choice for APIs. It allows small bursts while still enforcing long-term limits.
Leaky Bucket focuses on smooth traffic rather than fast responses. It works better for background processing than user-facing APIs.

Challenges in Distributed Systems

So far, everything we discussed assumes a single server.

In real-world applications, this is rarely the case.

Most systems run on multiple servers behind a load balancer.

This introduces a few important challenges for rate limiting.

Shared State Problem

If each server keeps its own rate limit counters:

one user can hit different servers,
each server thinks the user is under the limit,
the user ends up sending more requests than allowed.

This breaks the rate limit completely.

Consistency vs Performance

To fix this, servers need to share state.

But shared state brings trade-offs:

strong consistency is accurate but slow,
weak consistency is fast but slightly inaccurate.

Most real systems accept small inaccuracies to gain performance.

Time Synchronization

Many rate limiting algorithms depend on time.

In distributed systems:

server clocks may not be perfectly aligned,
small time differences can affect limits.

This needs to be handled carefully.

Key takeaway

Rate limiting becomes much harder once a system is distributed.

You must:

share state,
accept trade-offs,
balance accuracy and performance.

At a high level this blog covered how rate limiting works, why different algorithms exist, and why things become more complex once systems are distributed.

While exploring these ideas, I also implemented a complete distributed rate limiting system that applies the concepts discussed here.

If you're interested in seeing a real-world implementation,
you can find it here: github

Bit Manipulation

Guna Sai — Sat, 18 Oct 2025 13:36:49 +0000

Bit manipulation can be confusing at first, but it's super useful. You see it in lots of coding problems, and it can make your code faster, lighter, and handle tricky cases like combinations or states.

With a few simple tricks, you can do things like check if a number is a power of two, find the only unique number in an array, or quickly generate all subsets.

Let's look at some patterns I've found interesting and see how they actually work in practice.

Quick Bit Refresher

Before we get into patterns, here's a short review of the basic bit operators

Bitwise Operators

AND (&) - Keeps a bit set only if both are 1.
OR (|) - Sets a bit if any one of them is 1.
XOR (^) - Sets a bit if both are different.
NOT (~) - Flips all bits.
Left Shift (<<) - Moves bits to the left (like multiplying by 2).
Right Shift (>>) - Moves bits to the right (like dividing by 2).

Now it's all about spotting patterns and using them.

Common Bit Manipulation Patterns

These are some patterns that we see and are helpful to us

1. Check if a Number is a Power of Two

A number is a power of two if it has only one bit set.

For example, 1 (0001), 2 (0010), 4 (0100), 8 (1000), and so on.

The trick is simple:

n > 0 && (n & (n - 1)) == 0

How it works:
Subtracting 1 flips all bits after the rightmost set bit.
So, when you AND a number with n - 1, the result becomes zero only if there was just one bit set.

8 (1000)
7 (0111)
8 & 7 = 0000 -> Power of Two

When to use:
Useful when working with constraints like array sizes, segment trees, or memory blocks that must be powers of two.
Practice Problem:

Power of Two

2. Count Set Bits (Brian Kernighan's Algorithm)

Counting the number of 1s in a binary number can be done efficiently using this method.

The trick is simple:

int count = 0;
while (n>0) {
    n &= (n - 1);
    count++;
}

How it works:
Each time we do n & (n - 1), the rightmost set bit is removed.
We repeat this until the number becomes zero, counting how many bits were set.

13 (1101)
n = 1101 -> 1100 -> 1000 -> 0000
count = 3

When to use:
Useful in problems involving bit masks, subsets, or any situation where you need the number of set bits efficiently.

Practice Problems:

Number of 1 Bits
Counting Bits

3. Extract Rightmost Set Bit

Sometimes you need to isolate the least significant 1 bit in a number.

The trick is simple:

int right = n & -n;

How it works:
-n is the two's complement of n.
When you AND n with -n, all bits except the rightmost set bit become 0.

12 (1100)
-12 (0100 in effect for AND)
12 & -12 = 0100 -> 4

When to use:
Useful in submask iteration, Fenwick tree updates, and bit-based indexing.

Practice Problem:

XOR Queries of a Subarray

4. Swap Two Numbers Without Temp

You can swap two numbers without using an extra variable using XOR.

The trick is simple:

a = a^b;
b = a^b;
a = a^b;

How it works:
XOR has a property that allows you to combine and separate values.
After these three steps, the values of a and b are swapped.
Example:

a = 5 (0101)
b = 7 (0111)

Step 1: a ^= b -> a = 0101 ^ 0111 = 0010
Step 2: b ^= a -> b = 0111 ^ 0010 = 0101
Step 3: a ^= b -> a = 0010 ^ 0101 = 0111

When to use:
Useful in memory-constrained environments or when extra variables are not allowed.

Practice Problem:

do you actually need it 🤨

5. XOR Prefix Sum (Cumulative XOR)

XOR prefix sums help calculate the XOR of any subarray quickly.

The trick is simple:

prefix[i] = prefix[i - 1] ^ arr[i];
xor(l, r) = prefix[r] ^ prefix[l - 1];

How it works:
The XOR of a subarray from index l to r can be found by XORing the prefix up to r with the prefix up to l - 1.
This works because XOR is its own inverse.
Example:

arr = [1, 2, 3, 4]
prefix = [0, 1, 3, 0, 4]  // prefix[0] = 0
XOR(1, 3) = prefix[3] ^ prefix[0] = 0 ^ 0 = 0

When to use:
Useful in problems involving range XOR queries, parity checks, or XOR-based subarray problems.

Practice Problems:

XOR Queries of a Subarray
Single Number

6. Power of Four Check

A number is a power of four if it has only one bit set and that bit is in an even position (0-based index from the right).

The trick is simple:

public boolean isPowerOfFour(int n) {
    return n > 0 
        && (n & (n - 1)) == 0
        && (n % 3 == 1);
}

How it works:

n > 0 ensures the number is positive.

(n & (n - 1)) == 0 checks that the number has only one bit set.

n % 3 == 1 ensures that the set bit is at an even position. All powers of four (1, 4, 16, 64…) leave a remainder of 1 when divided by 3, which automatically eliminates numbers that are powers of two but not powers of four (like 2, 8, 32…).

Example:

16 -> binary 10000 (set bit at position 4, even)
16 > 0 True
16 & (16 - 1) = 16 & 15 = 0 True
16 % 3 = 1 -> Power of Four

8 -> binary 1000 (set bit at position 3, odd)
8 > 0 True
8 & (8 - 1) = 8 & 7 = 0 True
8 % 3 = 2 -> Not Power of Four

Practice Problem:

Power of Four

7. XOR from 1 to n Pattern

XOR of all numbers from 1 to n follows a repeating pattern every 4 numbers.

The trick is simple:

n % 4 == 0 -> result = n
n % 4 == 1 -> result = 1
n % 4 == 2 -> result = n + 1
n % 4 == 3 -> result = 0

How it works:

The XOR sequence repeats every 4 numbers, which allows you to find the XOR of 1 to n in O(1) time.
XOR has two key properties:

x ^ x = 0
x ^ 0 = x

If you look at the sequence of XOR from 1:

1 -> 1
1 ^ 2 -> 3
1 ^ 2 ^ 3 -> 0
1 ^ 2 ^ 3 ^ 4 -> 4
1 ^ 2 ^ 3 ^ 4 ^ 5 -> 1
1 ^ 2 ^ 3 ^ 4 ^ 5 ^ 6 -> 7
1 ^ 2 ^ 3 ^ 4 ^ 5 ^ 6 ^ 7 -> 0
1 ^ 2 ^ 3 ^ 4 ^ 5 ^ 6 ^ 7 ^ 8 -> 8

You can see the results repeat every 4 numbers: [n, 1, n+1, 0].

This happens because each group of 4 numbers cancels out in a specific way due to XOR properties.
Example:

XOR(1..5) -> 1^2^3^4^5
5 % 4 = 1 -> result = 1

When to use:

Useful in problems with range XOR queries, finding missing numbers, or single number problems.

Practice Problems:

Missing Number

XOR Operation in an Array

8. Subset Generation via Bitmask

You can generate all subsets of a set using bitmasks. Each element is either included or not included in a subset.

The trick is simple:

for (int mask = 0; mask < (1 << n); mask++) {
    for (int i = 0; i < n; i++) {
        if ((mask & (1 << i)) != 0) {
            // include element i in the subset
        }
    }
}

How it works:

Each number from 0 to 2^n - 1 represents a subset.

Each bit in the number decides whether to include the corresponding element in the subset.

Rightmost bit -> arr[0], next bit -> arr[1], and so on.

Example:

arr = [a, b, c]
mask = 5 -> binary 101
Check bits:
i = 0 -> 1 -> include a
i = 1 -> 0 -> exclude b
i = 2 -> 1 -> include c
Subset = {a, c}

Practice Problems:

Subset
Subsets II

9. Gray Code Conversion

Gray code is a binary sequence where two consecutive numbers differ by only one bit.

It is often used in hardware design or algorithms where minimal bit changes are required.

The trick is simple:

int gray = n ^ (n >> 1);
int binary = 0;
for (int g = gray; g != 0; g >>= 1) {
    binary ^= g;
}

How it works:

Binary to Gray:

Shift the number n one bit to the right.

XOR the original number with the shifted number.

This ensures that only one bit changes between consecutive numbers.

Gray to Binary:

Start with binary = 0.

Take the Gray code and repeatedly XOR it with itself shifted right.

This reconstructs the original binary number by accumulating changes from left to right.
Example:

Binary 5 -> 101
Shift right -> 010
XOR -> 101 ^ 010 = 111 -> Gray code

Gray 111 -> Binary:
Start binary = 0
Step 1: binary ^= 111 -> 111
Step 2: shift 111 >> 1 = 011, binary ^= 011 -> 100
Step 3: shift 011 >> 1 = 001, binary ^= 001 -> 101
Binary = 101 (original number)

When to use:

Useful in circular sequences where only one bit should change at a time.

Helpful in hardware counters, encoders, and minimizing errors during state changes.

Practice Problem:

Gray Code

10. Highest Set Bit (Most Significant Bit)

Finding the position of the highest set bit tells us the largest power of two less than or equal to a number.

The trick is simple:

int msb(int n) {
    int pos = 0;
    while (n > 0) {
        n >>= 1;
        pos++;
    }
    return pos - 1;
}

How it works:

Keep shifting the number right until it becomes zero.

Count how many shifts it takes. the last set bit before zero is the highest bit.

Example:

n = 10 -> binary 1010
Shift 1: 101 -> pos 1
Shift 2: 10 -> pos 2
Shift 3: 1 -> pos 3
Shift 4: 0 -> stop
Highest set bit position = 3 (value 8)

When to use:
Useful in bucket indexing, determining ranges of powers of two, or binary segmentation problems.

Practice Problems:

Number of 1 Bits
Missing Number

These are some patterns I found interesting and wanted to share from what I learned.

please give it a read

Guna Sai — Tue, 07 Oct 2025 16:55:23 +0000

Agentic AI: How LLMs Really Work Behind the Scenes

Gayathri Mangalarapu ・ Oct 7

#ai #llm #agenticai #tools

From HTTP to WebSockets: How Socket.IO Powers Real-Time Apps

Guna Sai — Sat, 16 Aug 2025 13:52:51 +0000

We live in a world where waiting even a few seconds feels like eternity. Imagine chatting with your friend and seeing their reply after 10 seconds… that’s not a conversation, that’s email!

If your app still needs a refresh to show what’s new, it already feels old. Think about a chat that lags, a scoreboard that updates late, or a game that’s out of sync. That tiny delay ruins the vibe.

That’s where real-time communication comes in, and it’s simpler than it sounds.

In this post, you’ll quickly learn:

Why HTTP falls short for “instant” experiences
What WebSockets are
A tiny client + server example you can copy-paste
Where Socket.IO helps (reconnects, rooms, events)

Let’s dive in

Why Do We Even Need Real-Time Communication?

Imagine watching a cricket match on TV where the score updates 5 minutes late. By the time you cheer for a six, the batsman’s already out. Feels wrong, right?

That’s exactly what happens when apps don’t update in real-time.

Chats -> need instant delivery (otherwise it feels like sending postcards).
Games -> need immediate sync (you can’t dodge an attack you see 3 seconds late).
Dashboards -> need live updates (a stock price that lags is basically useless).

Basically, real-time = the world as it happens.

HTTP vs WebSockets: The Classic Showdown

Let’s break it down in the simplest way possible

How HTTP Works (Request/Response)

Client ------------------> Server
"Hey, give me the latest news."

Client <------------------ Server
"Here's the news article."

Always client-initiated
Works perfectly for static content (like loading a webpage)
But if you need frequent updates? The client has to keep asking again... and again... (polling)

How WebSockets Work (Full Duplex)

Client <------------------> Server
"Ye"                    "What’s up?"
"Typing..."             "Seen ✔"
"Ping"                  "Pong"

Two-way street (client ↔ server)
Connection stays open after the handshake
Perfect for chats, games, dashboards where live sync is critical

Quick Comparison

Feature	HTTP	WebSockets
Communication Type	Request/Response (Half)	Full Duplex (Both directions)
Who Starts?	Always Client	Either Client or Server
Best For	Static pages, APIs	Real-time apps (chat, games)
Overhead	Higher (headers every req)	Lower (persistent connection)

Why Not Stick with HTTP?

The problem with plain old HTTP is that it was never designed for real-time communication.

Here’s what usually happens:

The client sends a request: “Got anything new?”
The server replies: “Nope, not yet.”
Two seconds later… the client asks again.

This constant back-and-forth is called polling.

It:

Burns bandwidth and server resources.
Feels unnecessarily slow.
Becomes painful for chat apps, games, or live updates.

It’s like standing next to your friend and asking every 2 seconds:

“Hey, are you there? Any news? How about now?”

WebSockets

WebSockets flip the game completely. Instead of knocking every few seconds,

The client and server just open one connection and keep it alive.

That means:

The client can send data whenever it wants.
The server can also push updates instantly.
No repeated “Are we there yet?” requests.

It’s like putting your friend on a call instead of texting every 2 seconds,
You both can talk naturally, in real-time, without the extra noise.

WebSockets in Action (Client + Server)

Think of WebSockets like a phone call; once connected, both sides can talk anytime. Let’s see it in code.

Server (Node.js)

const WebSocket = require("ws"); // Import the WebSocket library
const wss = new WebSocket.Server({ port: 8080 }); // Create server on port 8080

// When a client connects
wss.on("connection", ws => {
  console.log("New client connected!");

  // When server receives a message
  ws.on("message", message => {
    console.log(`Received: ${message}`);
    ws.send(`message received at server end`); // Reply back to client
  });

  // When client disconnects
  ws.on("close", () => {
    console.log("Client disconnected.");
  });
});

What’s happening here:

Server runs on port 8080.
When someone connects, it says “New client connected!”.
If the client sends a message, server replies back with “message received at server end”.
If they leave, it logs “Client disconnected.”.

Client (Browser JavaScript)

const socket = new WebSocket("ws://localhost:8080"); // Connect to server

// When the connection is ready
socket.onopen = () => {
  console.log("Connected to server");
  socket.send("hi server!"); // Send first message
};

// When server sends something
socket.onmessage = event => {
  console.log("Message from server:", event.data);
};

What’s happening here:

Client connects to the server (ws://localhost:8080).
As soon as it’s connected, it says “Hello Server!”.
Whenever server replies, client shows the message.

So in short:

The server waits for clients.
Client connects & sends messages.
Both can chat in real-time, just like WhatsApp, no repeated “Are you there?” checks.

Making Life Easier with Socket.IO

Think of WebSockets like a phone call -> fast, real-time talking.

Now, Socket.IO is like WhatsApp on your phone -> same call, but with extra powers:

Auto Reconnects -> If your internet drops, it joins back automatically.
Rooms/Groups -> Chat with multiple people at once.
Events -> Send specific messages (like "typing...", "joined", etc.), not just plain text.
Fallbacks -> If WebSockets don’t work, it uses another method to still connect.

In short:

Socket.IO = WebSockets + reliability + cool features.

WebSocket vs Socket.IO

Feature	WebSocket	Socket.IO
Real-time	✅ Yes	✅ Yes
Auto Reconnect	❌ No	✅ Yes
Rooms/Namespaces	❌ No	✅ Yes
Event-based Messages	❌ No	✅ Yes
Fallback Support	❌ No	✅ Yes

Socket.IO Example

Let’s look at a basic chat example using Node.js, Express, and Socket.IO.

Server (Node.js + Express + Socket.IO)

const express = require("express");
const http = require("http");
const { Server } = require("socket.io");

const app = express();
const server = http.createServer(app); // create HTTP server
const io = new Server(server); // attach socket.io to server

// Event: when a client connects
io.on("connection", socket => {
  console.log("a user connected");

  // Listen for "chat message" from client
  socket.on("chat message", msg => {
    // Broadcast the message to all connected clients
    io.emit("chat message", msg);
  });

  // Event: when client disconnects
  socket.on("disconnect", () => {
    console.log("user disconnected");
  });
});

// Start server
server.listen(3000, () => {
  console.log("listening on *:3000");
});

Explanation

http.createServer(app) -> creates an HTTP server from Express.
new Server(server) -> attaches Socket.IO to that HTTP server.
io.on("connection", ...) -> triggered whenever a client connects.
socket.on("chat message", msg => {...}) -> listens for messages sent from the client.
io.emit("chat message", msg) -> broadcasts the message to all connected clients.
socket.on("disconnect", ...) -> runs when a client disconnects.

Client (Browser JS)

<script src="/socket.io/socket.io.js"></script>
<script>
  const socket = io(); // connect to server

  // Event: when connected
  socket.on("connect", () => {
    console.log("Connected to server");

    // Send a chat message to server
    socket.emit("chat message", "Hello World!");
  });

  // Listen for chat messages from server
  socket.on("chat message", msg => {
    console.log("New message:", msg);
  });
</script>

Explanation:

<script src="/socket.io/socket.io.js"></script> -> loads Socket.IO client library.
const socket = io(); -> connects browser to server.
socket.emit("chat message", "Hello World!") -> sends message to server.
socket.on("chat message", ...)-> receives messages broadcasted by server.

Key Takeaway

Server: listens for events and broadcasts messages.
Client: connects, sends events, and listens for server broadcasts. This makes building real-time apps (like chat, live notifications, multiplayer games) super easy with Socket.IO.

Final Thoughts

HTTP works well for standard requests, but it is not designed for real-time communication.
WebSockets enable instant, two-way communication between client and server.
Socket.IO builds on WebSockets by adding reliability, ease of use, and useful features like rooms and reconnections.

In short, if you are building a chat app, live feed, or multiplayer game, WebSockets with Socket.IO can make the process much smoother.

Resources

DSA? Dev? Why Not Suffer Through Both?

Guna Sai — Sat, 19 Jul 2025 15:05:30 +0000

A personal journey through the noisy crossroads of problem-solving and product-building.

The Developer Dilemma

“Should I solve another Leetcode problem or build that SaaS idea?”

This isn't just a shower thought; it's a recurring loop every developer, especially students and self-learners, goes through. You're stuck between two equally demanding paths:

One says, "Crack DSA. Get that dream package."
The other whispers, "Ship fast. Build projects. Be a 10x dev."

But here's the catch: time isn't infinite, and doing both well feels overwhelming. You open VS Code to push that UI update, then Twitter hits you with “Solving 5 DSA problems a day changed my life.” So you panic-go to Leetcode. Then, midway through a binary search question, your brain says: “Wasn't I building a full-stack app a few minutes back?”

And this cycle repeats.

We're all stuck between two doors:

DSA (Data Structures & Algorithms): Logical thinking, coding interviews, and time complexities.

Dev (Development): Building real-world projects, deploying apps, and playing with tools.

It's not a lack of direction. It's too much direction, and that creates a new kind of confusion: productive anxiety.

The DSA Grind

Think DSA is just for interviews? Not really.

It's like a gym for your brain.

Helps you break big problems into bite-sized logic chunks
Makes for loops feel like second nature
Teaches you to smell brute-force like a code bloodhound

Real-world example?

Your dashboard is slow.

You’re mapping inside a filter, calling the DB twice, sorting for fun...

You stare at it like 😐, rewrite it using prefix sums or memoization, and now it loads in milliseconds.

That’s not magic. That’s you, with your DSA reps kicking in silently.

It’s less about bubble sort, more about knowing when not to write a nested loop that summons the devil.

Also, ever tried explaining recursion to an invisible person and accidentally become a philosopher?

Yeah. That’s character development.

The Dev Drive - Building Beyond the Console

DSA is cool... but Dev? Dev is alive.

There’s nothing like shipping something you built and seeing it live on the internet
From UI finesse to backend logic to DB schema. Dev lets you wear all the hats
You start appreciating how systems really talk: APIs, state, latency, user rage, everything
The bugs feel personal, and so do the wins

Analogy Time

If DSA is like sorting Lego blocks by size and color,

then Dev is building the entire Lego city.

You don’t just care about one block; you care how it fits, connects, and supports the structure.

Every piece matters. And when one breaks, the whole tower wobbles.

That’s the real power of Dev:

You don’t just solve problems. You design around them.

You start asking better questions:

Can this scale?
What happens if the DB goes down?
Can I decouple this logic?
Will users rage if it lags for 2 seconds?

Every project pushes you a level deeper, from styling a button to thinking about state management, rate limits, and user experience at scale.

Dev builds not just your resume, but your intuition.

When Worlds Collide - DSA Meets Dev

DSA isn't just for whiteboards. It’s quietly powering real-world apps.

Search bars? Behind that clean UI: binary search, trie.
Chat systems? Queues, hashing, and optimized data structures for real-time flow.
Pagination? Sliding window and prefix sums make it feel “infinite.”
Caching? LRU logic, maps, and heaps doing the heavy lifting.

DSA gives the “how.” Dev gives the “why.”

Ever fixed a slow feature and realized:

“Wait… this is just a DSA problem with users instead of testcases”?

Exactly that.

DSA trains you to think in edge cases.

Dev makes you build with edge users in mind.

Together? Clean logic, fast features, and few 3 am bug hunts.

My Path, My Puzzle

I started with DSA because I thought it was the only path to crack interviews.

Then came Dev, and suddenly I wasn’t solving problems, I was building stuff that mattered.

The FOMO hit hard.

While others were pushing ratings, I was debugging CSS and setting up MongoDB clusters.

Now?

I'm trying to balance both:

Solving 2-3 DSA problems daily
Building projects that excite me
Writing blogs when I get time to make sense of all this chaos

I'm not a pro yet, just a learner with a long to-do list and bugs as my bedtime stories.

The Reality Check

Still figuring things out?

Same here.

One day it's system design docs, the next it's a DP bug eating your brain.

And in between? Googling "how to center a div" for the 47th time.

Everyone’s journey looks different.

Some peak with DSA.

Some thrive in dev.

But most of us? We’re just out here trying, tinkering, switching tabs between LeetCode and localhost.

So don’t stress the choice.

You don’t have to pick sides. You can push both buttons.

But here's the real talk:

In the long run, you’ll need both.

DSA builds your core logic and problem-solving mindset.
Dev teaches you how that logic lives, breathes, and scales in the real world.

DSA vs Dev?

Naa. It’s DSA and Dev.

Let them coexist. That’s how we level up.

No Recursion, No Table, Still DP? My Shift From Brute Force to Intuition

Guna Sai — Fri, 13 Jun 2025 13:07:02 +0000

Wait... Is This Even DP?

When I started learning Dynamic Programming (DP), I thought I had it all figured out.

First write recursion ->
Then add memoization ->
Then convert to tabulation ->
And if you're feeling fancy, do space optimization.

Easy, right?

So whenever I saw a tough problem, my brain immediately went:

"Where’s the recursion? Let's add dp[i][j] and go"

That's how I thought DP was supposed to be.

But recently, I solved a problem... and it broke that pattern completely.

No recursion.

No DP array.

No i, no j, no table.

Still, it felt like Dynamic Programming.

And that's when I paused and asked myself:

“Wait… is this even DP?”

Turned out, it was. Just in disguise.

That's when I realized:

DP isn't just about writing recursion and caching it.

It's more about spotting repeated work and finding smart ways to reuse it.

Mind blown

The Problem

Max of Min for Every Window Size

You're given an array M of length N. For every window size i from 1 to N:

Find all subarrays of size i
Take the minimum of each subarray
From those, find the maximum
Store that in position i of a new array P

Example:

Input: M = [1, 2, 3]

Output: P = [3, 2, 1]

My Brute Force

The moment I read the problem, I felt confident.

"Sliding window + priority queue? Easy!"

I wrote it quickly.

Clean logic. Passed the sample cases.

Hit submit...

and TLE.

That hurt.
That's when I knew…

Maybe it's time to change my thinking.

Flipping the Perspective

Up to this point, I was stuck thinking:

"Fix a window size, slide it, take minimums."

But then I came across a different way of thinking (shoutout to ChatGPT for the nudge):

“What if instead of fixing the window… I fix the element?”

That led to a much better question:

"In how many windows is this element the minimum?"

This flipped everything.

Using a monotonic stack, I found:

left[i]: index of the previous smaller element
right[i]: index of the next smaller element

That gave me the range of window sizes where arr[i] is the minimum.

Now I could directly say:

int len = right[i] - left[i] - 1;
P[len] = max(P[len], arr[i]);

Array:        [10, 20, 30, 50, 10, 70, 30]
Indexes:        0   1   2   3   4   5   6

Fix element:              ↑
                         arr[4] = 10

Find:
   left[4]  = 0   (index of previous smaller)
   right[4] = 7   (index of next smaller)

Window size where arr[4] is min = right - left - 1 = 7 - 0 - 1 = 6

So, 10 is the minimum in all windows of size 6 that include index 4.

What DP Really Means

Dynamic Programming isn't about sticking to recursion or memo tables.

It's just... not doing the same work again and again.

Sometimes it shows up as a clever stack.

Other times, it's a loop with a trick.

And occasionally, it's just thinking from the other side.

I don't know all of it yet, but I've started noticing patterns I never used to.

Maybe that's what DP is not a formula, but a way of noticing.

Some Patterns I Started Noticing

After getting out of the “everything must be recursion” mindset, I started to notice some small things that helped.

Like:

If I keep doing the same thing on subarrays - maybe prefix sum or sliding window is the way.
If I'm checking min or max in ranges a lot - maybe a monotonic stack can save me.
If there are too many nested loops - maybe I can flip how I look at the problem.
And if recursion doesn't even fit - maybe it's just about reusing stuff smartly.

Still figuring it all out, but these small shifts made a big difference for me.

Final Thought

Okay yeah...

So all those “DP = recursion -> memo -> tabulation -> space optimization” steps?

Kinda feels silly now. 😅

This problem made me realize:

DP is just not doing the same thing twice, even if it doesn't look like typical DP.

And honestly?

That realization hit harder than a brute force TLE 💀

I'm still figuring things out, still breaking stuff.

But now I don't reach for recursion every time. I try to think smarter, not just code faster.

Many wrong solutions, many TLEs and a few tears later… I think I just changed my thinking 🙃

P.S.

Wanna know what broke my brain (in a good way)? Ping me. I’ve got more where that came from 😄