​

Today I implemented a Fixed Window Rate Limiter using Java, Spring Boot, and Redis.

What I learned:

- ✅ How Fixed Window rate limiting works

- ✅ Why it's simple and fast

- ✅ The boundary problem (traffic spikes at window edges)

- ✅ When to use Sliding Window, Token Bucket, and Leaky Bucket instead

Building these concepts from scratch has helped me understand the trade-offs much better than just reading about them.

I'm documenting my journey one topic at a time. Tomorrow I'll be implementing the Sliding Window Counter algorithm.

Feedback is always welcome. What rate-limiting algorithm do you use most in production, and why?

Today's milestone: Implemented the Fixed Window Rate Limiter using Java + Spring Boot.

A simple algorithm, but one of the core building blocks behind protecting APIs from abuse.

What it does

✅ Tracks requests within a fixed time window
✅ Allows requests until the configured limit is reached
✅ Returns HTTP 429 (Too Many Requests) when the limit is exceeded
✅ Automatically resets the counter when the next time window begins

The screenshots show:

• Spring Boot API (/api/ping)
• Custom rate-limiting filter
• Postman returning 429 Too Many Requests after exceeding the configured limit

Every rate-limiting algorithm solves the same problem differently. Over the next few days, I'll implement and compare:

• ✅ Fixed Window
• ⏳ Sliding Window Log
• ⏳ Sliding Window Counter
• ⏳ Token Bucket
• ⏳ Leaky Bucket
• ⏳ Distributed Rate Limiter using Redis

The goal isn't just to know these algorithms—it's to understand when to use each one and the trade-offs they make.

Which rate-limiting algorithm have you used in production, and why? 👇

#SystemDesign #Java #SpringBoot #BackendEngineering #RateLimiter #LearningInPublic #DistributedSystems #SoftwareEngineering

I genuinely never get bored of learning system design.

Instead of passively watching videos, I've started designing systems myself from scratch. It forces me to think about trade-offs instead of memorizing diagrams.

Today I worked on Designing a Distributed Rate Limiter.

Here's what I covered:

• Functional & non-functional requirements
• Back-of-the-envelope estimation (users, QPS, memory)
• High-level architecture
• API Gateway → Rate Limiter Service → Redis → Application Server
• Returning HTTP 429 for rate-limited requests
• Using Redis for fast request counting
• Thinking about scalability, availability, and low latency

While drawing the design, a few questions came to mind:

• When should we choose Token Bucket vs Sliding Window?
• How do companies like Google or Stripe handle rate limiting across multiple regions?
• What happens if Redis goes down? Do we fail open or fail closed?

I'm trying to understand the reasoning behind every design decision rather than just copying popular architectures.

If you're experienced with distributed systems, I'd love to know:

1. What's the biggest mistake beginners make while designing a rate limiter?
2. What would you improve in this design?
3. Any resources that helped you truly understand rate limiting?

Looking forward to your feedback. I'm planning to keep sharing one system design every day. 🚀

Without a Rate Limiter:

❌ Servers get overloaded

❌ APIs become slow or unavailable

❌ Bots and abusive users consume resources

❌ Genuine users suffer

A well-designed Rate Limiter solves these problems by controlling request flow while keeping latency low.

Key algorithms every backend engineer should know:

📌 Fixed Window Counter – Simple and fast

📌 Sliding Window Log – Most accurate, memory intensive

📌 Sliding Window Counter – Great balance of accuracy and performance

📌 Token Bucket – Handles burst traffic efficiently

📌 Leaky Bucket – Smooths traffic at a constant rate

Production Tips:

✅ Store counters in Redis with TTL

✅ Use atomic operations or Lua scripts to prevent race conditions

✅ Return HTTP 429 Too Many Requests when limits are exceeded

✅ Scale Redis using sharding for high traffic

✅ Monitor rate-limit metrics and tune limits based on usage patterns

If you're preparing for System Design or building scalable APIs with Java & Spring Boot, understanding rate limiting is a must-have skill.

Which rate-limiting algorithm do you prefer in production, and why? 👇

One of the biggest mindset shifts in System Design is learning to do Back-of-the-Envelope Estimation.

Before discussing databases, caches, or load balancers, ask:

👥 How many users?

⚡ How many requests per second?

💾 How much storage?

🌐 How much bandwidth?

🖥️ How much compute?

Example: A photo-sharing app with:

10M users

2 photos/user/day

2 MB per photo

That's roughly 14.6 PB of storage per year.

The goal isn't perfect accuracy—it's getting the right order of magnitude. These quick estimates help identify bottlenecks, choose the right architecture, and avoid over- or under-engineering.

Master this skill, and every system design interview becomes much easier.

What do you estimate first in a system design interview—QPS, storage, or bandwidth? 👇

The answer lies in 5 core distributed system concepts:

✅ Partitioning (Consistent Hashing)

✅ Replication

✅ GET & PUT Routing

✅ Data Versioning

✅ Gossip Protocol

I put together this one-page visual to simplify how DynamoDB achieves high availability, scalability, and eventual consistency.

If you're preparing for System Design interviews or learning Distributed Systems, save this for later.

Which distributed system should I break down next—Kafka, Cassandra, or Redis? 🚀

If you've ever prepared for a backend interview, you've probably come across these questions.

I recently revised SQL vs NoSQL and realized that understanding why each database exists is much more important than memorizing definitions.

Here's my quick recap:

📌 SQL (Relational Databases)

Structured data with predefined schema

Tables, rows, and relationships

ACID transactions for strong consistency

Ideal for financial and transactional applications

📌 NoSQL (Not Only SQL)

Flexible or schema-less data model

Built for horizontal scalability

Optimized for distributed systems

Great for handling massive volumes of data

Types of NoSQL

✅ Key-Value (Redis)

✅ Document (MongoDB)

✅ Column-Family (Cassandra)

✅ Graph (Neo4j)

Quick Comparison

Schema: Fixed vs Flexible

Scaling: Vertical vs Horizontal

Transactions: ACID vs BASE

Consistency: Strong vs Eventual (depending on implementation)

Best For: Complex transactions vs High-scale distributed applications

The biggest takeaway for me:

Choosing the right database isn't about SQL vs NoSQL—it's about choosing the right tool for the problem you're solving.

Every backend engineer should understand the trade-offs before making architectural decisions.

What's your go-to database for production applications, and why? 🚀

i want to prepare for sr data scientist in MAANG companies. My background is in  core ML, deeplearning, nlp etc. 

I plan to target in around a year from now.

Does someone have any idea about the interview preparation or someone in these companies who would like to share some experience?

Interviewprep resource:

PracHub: Company specific interview questions

DataLemur: SQL Interview and Data Science Interview questions

StrataScratch: SQL and Python interview