Forem: Omja sharma

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.