System Design for Junior to Mid Engineers: Rate Limiters, Caching, and Sharding Explained

System design interviews are no longer reserved strictly for staff engineers. Modern tech companies routinely test junior-to-mid level developers on basic architectural trade-offs, scalability bottlenecks, and distributed data storage concepts.

1. The 4-Step Interview Framework

When given a broad prompt (e.g., 'Design an API Rate Limiter' or 'Design TinyURL'), never jump straight into drawing boxes. Follow this structured roadmap: - Step 1: Clarify Scope & Functional Requirements (Who is using it? What are the core inputs and outputs? Read-heavy vs. write-heavy? Expected QPS and latency limits?) - Step 2: Back-of-the-Envelope Estimation (Calculate read/write QPS, peak throughput, storage growth per year, and memory caching requirements). - Step 3: High-Level Architecture (Define API endpoints, client-gateway routing, application services, cache layer, and database schema). - Step 4: Deep Dive & Bottleneck Mitigation (Address single points of failure, partition strategies, race conditions, and failover mechanisms).

2. Core Building Blocks Every Engineer Must Know

• Load Balancers: Layer 4 (TCP/UDP) vs Layer 7 (HTTP/HTTPS) routing algorithms (Round Robin, Least Connections, Consistent Hashing).
• Caching Strategies: Cache-Aside vs Write-Through vs Write-Back. Cache eviction policies (LRU, LFU) and preventing cache stampedes with probabilistic early expiration.
• Database Sharding & Partitioning: Range-based vs Hash-based partitioning. Managing cross-shard queries and resharding rebalances.
• Distributed Rate Limiting: Token Bucket and Leaky Bucket algorithms vs Sliding Window Log with Redis sorted sets.

3. Handling Data Consistency and Fault Tolerance

• CAP Theorem in Practice: Understanding why distributed systems must choose between Consistency (CP) and Availability (AP) during network partitions.
• Eventual Consistency: Using Message Queues (Kafka/RabbitMQ) for asynchronous decoupling and idempotent consumers to prevent duplicate processing.
• Database Replication: Primary-replica setups for read scaling, replication lag management, and automatic leader election via Raft/Zookeeper.