DEV Community: Omja sharma

The Load Balancer Is the Real Brain of Your Backend

Omja sharma — Wed, 29 Apr 2026 11:23:17 +0000

Every Request in Your App Passes Through This (and You Ignore It)

You add more servers

and expect your app to scale

It doesn’t

Because scaling isn’t about servers

it’s about how traffic is distributed

What actually happens

User → request → ???

Without a load balancer:

Some servers get overloaded
Others stay idle
Latency spikes
System crashes

Load balancer = traffic controller

It sits in front of your backend

and decides:

"Which server should handle this request?"

Common strategies

Round Robin

Distribute requests evenly
Works if all servers are equal

Least Connections

Send traffic to least busy server
Better for real-world usage

IP Hash

Same user → same server
Useful for sessions

The real issue

Not all requests are equal

One request = 10ms

Another = 2 seconds

If distribution is naive

your system still breaks

Types

Layer 4

Fast
Based on IP/port

Layer 7

Smarter
Routes based on URL, headers

Example:

/api → backend
/images → CDN

Things most devs miss

No health checks → dead server still gets traffic
No failover → single point of failure
Assuming more servers = scale

Reality

Scaling isn’t adding machines

It’s controlling traffic intelligently

That’s where systems either survive

or collapse

Caching Explained: How Redis Works in Real-World System Design

Omja sharma — Sat, 25 Apr 2026 19:47:54 +0000

Your App Isn’t Slow — Your Caching Strategy Is Broken

Most devs blame code for performance issues

Wrong.

You're just hitting the DB too often.

What caching does

Store frequently used data
Avoid repeated DB calls
Serve responses instantly

Basic flow

User requests data
Check cache
If present → return instantly (cache hit)
If not → fetch from DB (cache miss)
Store in cache
Return response

That's the entire game.

Cache hit vs miss

Cache hit → fast response (milliseconds)
Cache miss → slow response (DB query)

Your entire system performance depends on this.

Redis basics

In-memory → super fast
Key-value store
Supports TTL
Used everywhere at scale

Biggest problem

Cache invalidation

Data updates

Cache doesn’t

→ stale results

Common Caching Strategies

Cache Aside (Most Common)
App checks cache first
On miss → fetch from DB → update cache
Simple. Flexible. Widely used.
Write Through
Write goes to cache AND DB together
Safer, but slower writes.
Write Back (Advanced)
Write goes to cache first
DB updated later
Fast, but risky if not handled well.

Golden rules

Always use TTL
Don’t cache everything
Handle misses properly
Never treat cache as DB

Caching isn’t optional at scale

It’s the difference between smooth and broken systems

Consistent Hashing Explained: The Trick That Keeps Systems Running When Servers Fail

Omja sharma — Fri, 24 Apr 2026 11:09:32 +0000

Add one server? Everything reshuffles.

Remove one server? Cache gets wiped.

Traffic spikes? System collapses.

This is exactly the problem consistent hashing solves.

The Problem with Traditional Hashing

In a basic setup, you assign requests like this:

server = hash(key) % N

Where:

key = user ID / request ID
N = number of servers

Sounds fine… until N changes.

What breaks?

If you go from 3 → 4 servers:

Almost all keys get remapped
Cache becomes useless
Database gets slammed
Latency spikes

This is called the rehashing problem.

Enter Consistent Hashing

Consistent hashing avoids this chaos.

Instead of mapping keys directly to servers, it maps both servers and keys onto a ring.

How it works

Imagine a circle (0 → 360 degrees or hash space)
Hash each server → place it on the ring
Hash each key → place it on the same ring
A key is assigned to the next server clockwise

That’s it.

Why This Works

When a server is added or removed:

Only a small portion of keys move
Most of the system remains untouched

No massive reshuffling. No meltdown.

Real-World Example

Let’s say:

You have 3 cache servers
You store user sessions

Without consistent hashing:

Adding a server invalidates almost all sessions

With consistent hashing:

Only a fraction of users get reassigned
System stays stable

But There’s a Catch

Servers might not be evenly distributed on the ring.

This creates:

Uneven load
Hotspots

Solution: Virtual Nodes

Instead of placing each server once:

Place it multiple times on the ring

Example:
Server A → 100 positions

Server B → 100 positions

Now distribution becomes much more balanced.

Where It’s Used

Consistent hashing powers systems like:

Distributed caches (Redis clusters)
CDNs
Databases like Cassandra
Load balancers

If you’ve used Netflix, Amazon, or any large-scale system — this is already working behind the scenes.

When Should You Use It?

Use consistent hashing when:

You have distributed systems
Servers scale dynamically
Cache stability matters
You want minimal disruption during changes

Common Mistake

Most engineers:

Learn hashing
Ignore what happens when servers change

That’s where real systems break.

Consistent hashing is not optional at scale — it’s foundational.

Reacp:

Scaling isn’t just about adding servers.

It’s about how gracefully your system adapts when things change.

Consistent hashing is one of those simple ideas that quietly prevents disasters.

If you're building anything distributed — you need this.

Rate Limiter Explained: Everything You Need in 5 Minutes

Omja sharma — Fri, 10 Apr 2026 08:54:27 +0000

What happens if one user sends 10,000 requests per second to your API?

Your system crashes.
Unless you have a rate limiter.

What is Rate Limiting?

Rate limiting controls how many requests a user can make in a given time.

Example:
100 requests per minute per user
If the limit is exceeded:

requests are blocked
or delayed

Why It Matters

Without rate limiting:

APIs get overloaded
systems crash under traffic spikes
abuse (spam, brute force) increases

Common Approaches

1. Fixed Window

Limit requests in a fixed time window.

Example:
100 requests per minute
Problem:
Burst traffic at window edges

2. Sliding Window

Tracks requests over a rolling time window.

Better accuracy than fixed window

Slightly more complex

3. Token Bucket

Tokens are added at a fixed rate.

Each request consumes a token.

If no tokens:
request is rejected

Best for handling bursts

4. Leaky Bucket

Requests are processed at a constant rate.

Extra requests are queued or dropped.

Good for smoothing traffic

How It’s Implemented

Typical setup:

API Gateway or middleware
Redis for storing counters
Key = user/IP
Value = request count

Redis is used because:

fast
supports atomic operations
works well at scale

Trade-offs

accuracy vs performance
memory usage
handling bursts

No single approach is perfect.

Where It’s Used

login attempts
public APIs
payment systems
search endpoints

Rate limiting is not just about blocking users.

It’s about protecting your system from overload.

A small feature that prevents big failures.

[Boost]

Omja sharma — Thu, 09 Apr 2026 11:41:35 +0000

Omja sharma

Apr 8

System Design Basics: How Systems Actually Scale

Comments

1 min read

Why Systems Fail Under Load (and How to Fix Them)

Omja sharma — Thu, 09 Apr 2026 11:32:58 +0000

Your system won’t fail because of code.

It will fail because of scale.

Here’s what actually breaks systems in production and how to fix it.

1. Database Overload

Problem:
Too many reads/writes hit the database.

Symptoms:

slow queries
timeouts
high CPU usage

Fix:

add caching (Redis)
use read replicas
optimize queries and indexing

2. Single Server Bottleneck

Problem:
Everything runs on one server.

Symptoms:

crashes under traffic
downtime

Fix:

add more servers
use horizontal scaling

3. No Load Balancing

Problem:
Traffic is not distributed.

Symptoms:

uneven load
some servers idle, others overloaded

Fix:

introduce a load balancer

4. No Caching

Problem:
Every request hits the database.

Symptoms:

high latency
slow responses

Fix:

cache frequently accessed data
store sessions and API responses in Redis

5. Blocking Operations

Problem:
Heavy tasks run in request cycle.

Examples:

sending emails
processing files

Symptoms:

slow APIs
request timeouts

Fix:

move work to background jobs
use message queues

6. Traffic Spikes

Problem:
Sudden increase in users.

Symptoms:

system crashes
request failures

Fix:

auto-scaling
rate limiting
load balancing

7. Large Dataset Growth

Problem:
Database becomes too large.

Symptoms:

slow queries
scaling issues

Fix:

database sharding
partitioning

8. No Monitoring

Problem:
You don’t know what’s happening.

Symptoms:

issues detected too late

Fix:

track latency, errors, traffic
use monitoring tools

Final Thought

Systems don’t fail randomly.

They fail in predictable ways.

System design is not about building perfect systems.

It’s about identifying bottlenecks and fixing them before they break.

System Design Basics: How Systems Actually Scale

Omja sharma — Wed, 08 Apr 2026 21:22:57 +0000

Most systems don’t start distributed. They start simple and evolve with scale.

Here’s the typical flow.

1. Single Server

Everything runs on one machine:

application
database Easy to build, easy to break.

2. Split Application and Database

Move database to a separate server.
Benefits:

better performance
independent scaling

3. Horizontal Scaling

Add multiple application servers.
Now the system can handle more traffic.
Problem:
How do users reach the right server?

4. Load Balancer

Distributes incoming requests across servers.
Benefits:

avoids overload
improves availability

5. Database Replication

Primary database handles writes

Replicas handle reads

Benefits:

reduces load on primary
improves read performance

6. Caching

Use Redis or in-memory cache.
Store:

frequently accessed data
session data Benefits:
faster responses

- fewer database queries

7. CDN

Serve static files closer to users.
Benefits:

lower latency
reduced backend load

8. Message Queue

Use queues for async work:

emails
notifications
background jobs Benefits:
decouples system
improves reliability

9. Database Sharding

Split data across multiple databases.
Benefits:

handles large scale Tradeoff:

- added complexity

10. Monitoring

Track:

latency
errors
traffic Without this, you are blind.

Key Idea

Systems are not designed for scale from day one. They evolve as bottlenecks appear.