Learning System Design in Public 🚀 | Day 1: Rate Limiter Design

Instead of just watching videos, I decided to practice system design like a real interview.

Today I started with one of the most common interview questions:

Design a Rate Limiter for an API Gateway.

I didn't jump straight into the architecture.

I started with Requirement Gathering, just like in an actual interview:

  • Functional requirements
    • 100 requests/minute per user
    • Return HTTP 429 when the limit is exceeded
    • Validate every request before it reaches the backend
  • Non-functional requirements
    • Low latency (<5 ms)
    • High availability
    • Horizontal scalability
    • Support millions of users

Before designing anything, I asked myself:

>

Because asking the right questions is often more important than drawing boxes.

Next, I'll discuss:

  • Requirement clarification
  • Capacity estimation
  • High-level design
  • Rate limiting algorithms
  • Distributed architecture
  • Scaling and trade-offs

I'm building this incrementally and sharing every step.

Feedback and interview tips are always welcome! 🚀

reddit.com
u/Creative_Fox_8836 — 24 days ago
▲ 0 r/midleveldeveloper+1 crossposts

Why can DynamoDB handle millions of requests per second while a traditional database struggles? 🤔

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? 🚀

u/Creative_Fox_8836 — 28 days ago
▲ 7 r/midleveldeveloper+2 crossposts

🤔 SQL or NoSQL? ACID or BASE? Vertical Scaling or Horizontal Scaling?

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? 🚀

u/Creative_Fox_8836 — 28 days ago

🚀 Designing a Scalable File Storage System (Dropbox-like)

Recently, I worked on designing a cloud-based file storage system that supports upload, download, sharing, and syncing across devices. Here’s a quick breakdown 👇

🔹 Core APIs

POST /files → Upload file + metadata

GET /files/{fileId} → Download file

POST /files/{fileId}/share → Share with users

🔹 High-Level Design (HLD)

API Gateway (Auth, Routing, Rate Limiting)

File Service (handles metadata & logic)

Blob Storage (e.g., S3) for actual files

NoSQL DB for metadata

CDN for fast downloads

🔹 Key Challenges & Solutions

✅ Large File Uploads

Chunking (split into smaller parts)

Parallel uploads + resumable support

ETag-based chunk validation

✅ Scalability

Direct upload via pre-signed URLs

CDN caching for frequently accessed files

✅ Sharing

Share table mapping users ↔ files

Secure access using tokens/links

✅ Reliability & UX

Progress indicators

Retry + resume on failures

🔹 Security

Encryption (at rest & in transit)

Authentication + Authorization

💡 Takeaway:

Designing such systems is all about balancing scalability, reliability, and user experience while keeping latency low.

👉 I’ll be sharing the GitHub implementation soon—stay tuned!

Would love feedback or suggestions to improve this design 🙌

#SystemDesign #BackendDevelopment #ScalableSystems #Cloud #SDE #Tech #LearningInPublic

u/Creative_Fox_8836 — 4 months ago