Class 10 Pre-Class: URL Shortener Interview Mastery
+ Redis Deep Dive

The URL shortener is the most frequently asked system design question. It appears in interviews at Google, Meta, Amazon, Microsoft, and virtually every tech company. The question seems simple but tests every fundamental concept: caching, database design, code generation algorithms, scaling, and trade-off analysis. This section shows you exactly what interviewers look for at each phase and what mistakes lose you points.

This is the reference diagram you should be able to draw from memory in under 5 minutes. Every component is labeled with a specific technology. Both the read path (GET /{code} → CDN → Redis → PostgreSQL) and write path (POST /urls → KGS → PostgreSQL → Redis) are annotated. The async analytics pipeline (Kafka → ClickHouse) is separate from the hot path. The rate limiter protects the write endpoint.

After you present your design, interviewers will probe with follow-up questions. These are not trick questions — they test whether you understand the edge cases and can think on your feet. Here are the six most common follow-ups and how to answer them.

Redis (Remote Dictionary Server) is the most widely used in-memory data store in system design. It appears in virtually every interview answer — for caching, session storage, rate limiting, distributed locks, leaderboards, and message queues. Understanding Redis deeply is a prerequisite for senior engineering roles and system design interviews at any level.

Why Redis is so fast:

• In-memory: All data lives in RAM. A Redis GET takes ~0.1ms compared to ~5ms for a PostgreSQL indexed read (50× faster) or ~50ms for a disk-based NoSQL read (500× faster). This speed comes from avoiding disk I/O entirely for reads.
• Single-threaded: Redis processes all commands on a single thread using an event loop (epoll/kqueue). No lock contention, no context switching, no thread synchronization overhead. One thread can handle 100K–500K operations per second because each operation is sub-microsecond.
• Efficient data structures: Redis uses optimized in-memory data structures: SDS (Simple Dynamic Strings), ziplist (compact encoding for small collections), skiplist (sorted sets), hash tables. These are purpose-built for speed, not disk efficiency.

Most developers think of Redis as a simple key-value cache (GET/SET). In reality, Redis supports six major data structures, each with specific use cases in system design. Knowing the right data structure for each problem is what separates a junior answer ("I use Redis for caching") from a senior one ("I use a Redis Sorted Set for the leaderboard because ZADD gives O(log n) inserts").

Redis appears in system design interviews for eight primary use cases. You will use at least two in every interview. The most common are caching (90% of designs), rate limiting (50%), session store (40%), and distributed locks (30%). For each, know the Redis command pattern, the configuration, and an example system.

When Redis reaches its configured maxmemory limit, it must decide what to evict. The eviction policy determines which keys are removed to make room for new writes. The production standard is allkeys-lru: evict the least recently used key from the entire keyspace. This ensures the cache always holds the hottest data without any manual management. Never use noeviction in production — it returns errors when memory is full, which breaks writes.

Redis stores all data in memory, but it can persist to disk for recovery after a restart. Two persistence mechanisms exist and can be used together. RDB (Redis Database) takes periodic full snapshots (every 60s if 1,000+ keys changed) — fast recovery but up to 60s data loss. AOF (Append-Only File) logs every write command — at most 1 second data loss with fsync=everysec. Use both in production.

Redis Sentinel: Provides high availability for a single Redis node. Three Sentinel processes monitor the primary. If the primary fails, Sentinels elect a new primary from the replicas (automatic failover in ~10 seconds). All data is on one node. Use when your dataset fits in one node's memory (typically <64 GB). This is sufficient for most URL shortener and caching use cases.

Redis Cluster: Provides both HA and horizontal scaling. Data is sharded across N primary nodes using 16,384 hash slots. Each primary has one or more replicas. The client hashes each key to determine which shard it belongs to. Use when you need more capacity than one node (>64 GB) or more throughput than one node (>500K ops/sec). Instagram's feed cache uses Redis Cluster with 50+ nodes.