URL Shortener
from Zero to Staff Engineer

Always start by establishing numbers. DAU, reads/sec, writes/sec, storage. Every design decision follows from scale. A system for 1000 users is completely different from one for 100 million.

At each scale level, identify the bottleneck. DB at 1000 r/s. Cache miss at 10,000 r/s. Network at 100,000 r/s. Hot partition at 1M r/s. Design is about managing bottlenecks.

This single choice drives 80% of your architecture decisions. For URL shortener: Availability. A stale redirect is OK. A 503 error is not. This justifies Cassandra, eventual consistency, async replication.

URL shortener is 100:1 read-heavy. This justifies: separate read DB, heavy caching, read replicas, CDN. If it were write-heavy, the entire architecture would differ.

Characters: a-z (26) + A-Z (26) + 0-9 (10) = 62 characters. All URL-safe. No encoding needed.

Base64 uses + and / which are URL-special characters. They need percent-encoding in URLs. Base62 avoids this entirely.

base62^6 = 56 billion combinations. base62^7 = 3.5 trillion. 18.25 billion records over 5 years fits comfortably in 7 chars with room to spare.

Base58 (used by Bitcoin) removes visually confusing chars: 0, O, l, I. Valid choice if URLs will be typed by humans. Minor trade-off: slightly fewer combinations per character.

Hash the long URL with MD5, take first 6 characters of the hex output, encode as base62.

Birthday paradox: with 56B combinations and 18B URLs, collision probability grows non-linearly. At 50% of space used, ~50% of new URLs collide. Retry loop under heavy load becomes O(n) unbounded.

Pre-generate thousands of unique short codes and store them in a pool table. On write request: atomically pop one. Refill the pool asynchronously when it drops below threshold.

Removes all collision handling from the write path. The pool contains only unique, verified codes. Pop is O(1), no retries, no race conditions within a region.

When write latency must be ultra-low and predictable. When you can afford a background job for pre-generation. Not suitable if you need truly random-looking URLs with no pattern.

SELECT ... FOR UPDATE SKIP LOCKED is the key. Multiple workers can pop from the pool concurrently — each skips rows already locked by others. No deadlocks, no waits, true parallelism.

O(1) write path. No collisions at runtime. Predictable latency. Easy to monitor pool health. Survives burst traffic (pool absorbs the load).

Cross-region coordination is impossible — two regions cannot share one pool without a central coordinator (defeats the purpose). Solution: regional pools with prefixes.

A 64-bit integer composed of: timestamp bits + region/node ID bits + sequence bits. No database needed. Each server generates IDs independently. Then base62-encode the integer to get the short code.

Uniqueness is guaranteed by construction: same timestamp + same node can never produce the same sequence number. No central coordinator. No lock. Pure mathematics.

When the pool is empty (circuit breaker fallback). When you want no-dependency ID generation. When you need IDs to be monotonically increasing (good for DB B-tree index locality).

41 bits for timestamp (69 years), 6 bits for region (64 regions), 6 bits for node (64 nodes per region), 11 bits for sequence (2048 IDs per millisecond per node). Total: 64 bits.

No coordinator. No database. No collision. Sortable by time. Good B-tree locality. Survives any infrastructure failure.

Clock skew: if a server's clock drifts backward, you can generate duplicate IDs. Mitigation: wait until clock catches up, or use NTP with tight synchronisation.

A circuit breaker monitors the health of a resource (here: the URL pool). When the pool is empty or the refill job is dead, it "trips" and switches the entire system to a fallback path.

Without a circuit breaker: empty pool → all writes fail → service down. With circuit breaker: empty pool → switch to Snowflake ID generation → service continues at slightly higher latency. Graceful degradation over hard failure.

CLOSED: Normal. Pool requests flow through. OPEN: Pool failed. All requests routed to Snowflake fallback. HALF-OPEN: Probe: try pool once. If succeeds, close. If fails, stay open.

Prevents cascading failures. Automatic recovery. No human intervention needed. System survives a dead refill job at 3 AM.

State management complexity. False positives can unnecessarily switch to fallback. Need tuning: how many failures trigger open state? How long before half-open probe?

Any time you have a primary path and a fallback path. Pool vs Snowflake. Redis vs DB. Primary region vs secondary region.

A Java in-memory cache running inside the same JVM as your application. No network call. Sub-millisecond access. Uses the W-TinyLFU algorithm for near-optimal eviction.

Guava uses LRU (Least Recently Used). Caffeine uses W-TinyLFU — a window-based tiny least-frequently-used algorithm. W-TinyLFU achieves near-optimal hit rate for skewed (Zipf) distributions like URL access patterns. 10-30% better hit rate than pure LRU.

Uses a Count-Min Sketch (probabilistic frequency counter, O(1) space) to estimate how often each key is accessed. Items admitted to main cache only if their frequency exceeds the victim being evicted. A "window" cache handles newly popular items before they have frequency history.

Any read-heavy Java application. Data that fits in heap memory (10k–500k entries). When network round-trip to Redis would dominate latency.

Zero network overhead. Sub-microsecond access. No external dependency. Survives Redis outage. Best hit rate for skewed access patterns.

Per-JVM cache — 10 instances = 10 separate caches. Cache staleness between instances (eventual consistency). Consumes JVM heap. Lost on restart. Not shared across services.

An in-memory key-value store running as a separate service, shared across all application instances in a region. Accessed via network (< 1ms within same datacenter).

Redis supports data structures (strings, hashes, sorted sets, counters), persistence, pub/sub, Lua scripting, and cluster mode. Memcached is simpler but has no persistence or advanced structures. Redis is the default choice for most production systems.

With maxmemory-policy allkeys-lfu, Redis uses LFU to decide what to evict. It maintains a frequency counter per key (using a probabilistic approximation — Morris counter). Keys with lowest frequency are evicted first, regardless of recency. Perfect for URL shortener — viral URLs stay cached even if not accessed for hours.

Shared cache across multiple application instances. Data too large for L1 heap. When you need persistence (RDB/AOF) or pub/sub. Cross-service caching.

Shared across all instances (no per-instance staleness). Large capacity (limited by RAM). Rich data structures. TTL per key. Atomic operations. Persistence options.

Network hop (1–5ms). Single point of failure (mitigated by Redis Sentinel or Cluster). Memory cost. Serialisation overhead. Cluster resharding complexity.

A popular URL's cache entry expires. At that exact moment, 10,000 simultaneous requests arrive. All miss the cache. All 10,000 hit Cassandra simultaneously. Cassandra gets overloaded and dies. System cascades to failure.

Viral URLs get massive concurrent traffic. TTL expiry is a simultaneous event. Without protection, the cache miss translates directly to a DB spike proportional to traffic volume.

SETNX = SET if Not eXists. First thread to call it "wins" and fetches from DB. All others see the lock exists and wait. When the winner populates the cache, all others read from cache. DB sees only 1 request instead of 10,000.

DB sees exactly 1 request per cache miss, regardless of concurrent traffic volume. Thundering herd completely eliminated.

Lock holder crashes mid-fetch → lock never released → all waiting threads starve. Mitigation: always set a TTL on the lock (e.g. 500ms). If TTL expires without cache being populated, next thread retries.

Cache stampede, dogpile effect. Same problem, different names. Know all three terms.

A distributed network of edge servers globally (CloudFront, Fastly, Cloudflare). Caches the redirect response (302 + Location header) at the edge closest to the user. Tokyo user gets served from Tokyo edge, not from your US-East datacenter.

Eliminates intercontinental latency for hot URLs. A cache hit at CDN = ~5ms instead of ~200ms (Asia→US round trip). For viral URLs with millions of clicks, CDN handles 99% of load without touching your infrastructure.

CDN cache is hard to invalidate instantly. Purging a URL from all global edge nodes takes 1–5 minutes. If you delete or update a URL, users may get the old redirect for minutes. This is why CDN TTL should be short (1 hour max) for mutable URLs.

Call CDN invalidation API (e.g. CloudFront CreateInvalidation) when a URL is updated or deleted. Propagates globally in 1–5 minutes. For instant invalidation, use short TTL instead of explicit purge.

A relational database with full ACID guarantees, used exclusively for the write path. All URL creation, update, and deletion goes here. Never touched by the read path.

ACID transactions ensure no duplicate short codes. UNIQUE constraint is a hard database-level guarantee. WAL (Write-Ahead Log) enables reliable async replication to Cassandra and other replicas. Rich SQL for complex write-side queries (user dashboards, bulk operations).

Atomicity: Write succeeds entirely or fails entirely. No partial writes. Consistency: UNIQUE constraint enforced at DB level. Isolation: Concurrent writes don't interfere. Durability: Committed writes survive crashes (WAL + fsync).

Doesn't scale horizontally for reads (hence Cassandra for reads). Single-region primary means intercontinental writes have higher latency. Complex sharding if writes exceed single-machine capacity.

A distributed NoSQL database optimised for high-throughput key-value reads. Multi-region active-active. No single point of failure. Scales horizontally by adding nodes.

Our read pattern is simple: given short_code, return long_url. Cassandra is a masterclass at exactly this — single-key lookups at massive scale. It distributes data across nodes using consistent hashing, so any node can serve any key. Adding more nodes linearly increases throughput.

In Cassandra, the partition key determines which node stores the data. Our partition key = short_code. High cardinality (millions of unique codes) means data is spread evenly across all nodes. No hot partitions.

Cassandra maps each short_code to a token on a ring. Each node owns a range of tokens. When a node is added or removed, only the adjacent tokens are remapped — not all data. This is why Cassandra scales without downtime.

Active-active multi-region. No primary node (any node can serve reads). Linear scalability. Tunable consistency (ONE, LOCAL_QUORUM, QUORUM). Built-in replication factor. No joins = no lock contention.

No ACID. No joins. No secondary indexes at scale. Schema must be designed for access patterns (not normalisation). Compaction can cause latency spikes. Repair jobs required for consistency.

A viral URL (e.g., World Cup score link) gets 10 million clicks in 60 seconds. All clicks → same Cassandra partition key → same node → node CPU at 100% → reads slow → eventually node dies → other nodes can't replicate fast enough → cascade failure.

Add a bucket_id to the partition key. Bucket = hash(short_code) % N. Since the hash is deterministic, both read and write always go to the same bucket — no scatter-gather needed. Spreads load across N partitions.

Random bucket on write, then scatter-gather on read (query all N buckets). This turns 1 read into N reads. At 10M r/min with N=100, you get 1 billion Cassandra queries per minute. Worse than the original problem.

Consistent hashing + deterministic bucket = no coordination needed. Write knows exactly which bucket. Read knows exactly which bucket. O(1) lookup, load spread across N nodes.

A columnar OLAP (Online Analytical Processing) database designed for high-speed aggregations over large datasets. Stores data column-by-column instead of row-by-row.

Query: "total clicks on URL X per hour for the last 30 days." This reads only the click_count and click_hour columns — ignoring all other columns. Row-based DBs read entire rows even for single-column aggregations. Columnar = 10-100x faster for analytical queries.

Never in the write path. Kafka consumer reads url.clicked events → aggregates → bulk inserts into ClickHouse. Decoupled from user-facing latency. Analytics can be delayed by seconds or minutes — that's acceptable.

BigQuery (Google's managed columnar DB) when you want zero infrastructure management. ClickHouse when you want self-hosted with more control and lower cost at scale. Both are columnar, append-only, eventual consistency.

Eric Brewer's theorem (2000): In the presence of a network Partition, a distributed system must choose between Consistency and Availability. You cannot guarantee both.

Network partitions are not theoretical — they happen in production regularly (switch failure, network congestion, datacenter isolation). When they happen, your design choice determines whether users see stale data or no data at all.

AP — Availability over Consistency. A stale redirect (301→old URL) is a minor UX issue. A 503 Service Unavailable during a partition is catastrophic. We choose to serve potentially stale data rather than refuse requests.

"CA systems" (consistent AND available, no partition tolerance) only exist as single-node databases. Any networked distributed system MUST tolerate partitions — the real choice is always C vs A during a partition.

Tokyo user creates a short URL → written to US-East primary PostgreSQL → async replicated to Asia Cassandra (200ms lag). 50ms later: same user clicks the URL → Asia Cassandra → not replicated yet → returns 404. User sees their own creation fail immediately. Terrible UX.

After a write, return a token: X-Write-Region: us-east, X-Write-Ts: 1234567890. Client sends this header on next request. Gateway sees it and routes reads to US-East for 5 seconds. After 5s, Asia has the data and normal routing resumes.

If Asia Cassandra returns null: retry the read against US-East PostgreSQL (source of truth). Cache the result locally in Asia Cassandra (async repair). User gets their URL. Slight tail latency increase but correct result.

Use Spanner or CockroachDB with globally synchronous writes. Solves problem perfectly. But: 200ms write latency (US-to-Asia synchronous), 10× cost, operational complexity. Only justified if business requirement explicitly demands it.

Producer waits for ALL in-sync replicas (ISR) to acknowledge the message before considering it sent. Maximum durability. If the leader dies after acks=all, at least one replica has the message. No data loss.

Minimum number of replicas that must be in-sync for a produce request to succeed. With RF=3 and min.insync.replicas=2: if 2 replicas die, writes fail (rather than risking data loss). This is the safety floor.

Makes the producer exactly-once at the broker level. Each message gets a sequence number. If a retry delivers a duplicate (network timeout after send), broker deduplicates using the sequence number. Enables exactly-once semantics.

Kafka remembers where each consumer group left off (the offset). If a consumer crashes and restarts, it picks up from where it stopped. No message loss, no re-processing (with idempotent consumers). Offset committed to __consumer_offsets internal topic.

At-least-once: messages delivered one or more times. Consumer must be idempotent (handle duplicates). Simpler to implement. Exactly-once: requires idempotent producer + transactional consumer. Harder but no duplicates. For analytics, at-least-once + idempotent aggregation is fine.

When a consumer fails to process a message after max retries (e.g., malformed event), it sends the message to a DLQ topic instead of blocking. The main consumer continues. DLQ messages are inspected manually or by a separate consumer. Never let one bad message block the entire consumer.

Kafka's built-in cross-cluster replication tool. Mirrors topics from source cluster (US-East) to target clusters (EU, Asia). Both analytics and DR use this.

If US-East Kafka cluster dies, EU Kafka cluster has a mirror of every event up to the moment of failure. When US-East recovers, it can replay from the EU mirror. This bounds RPO to the MirrorMaker replication lag — typically under 1 second.

Offset translation: the same message has different offsets in source and mirror clusters. MirrorMaker 2 provides offset translation APIs, but consumers must use them correctly when switching clusters during failover.

Confluent's commercial cross-cluster replication. More features, better monitoring, easier offset management. Worth considering for production if budget allows.

Maximum amount of data loss acceptable. "How far back in time can we afford to roll back?" Our target: RPO ≤ 1 second, bounded by Kafka replication lag. Without Kafka: RPO = undefined (could be minutes of lost writes).

Maximum acceptable downtime. "How fast must we recover?" Our target: RTO ≤ 60 seconds for automatic failover (GeoDNS TTL + health check time). Full recovery (US-East back online): 30-60 minutes for safe canary ramp.

Every write event is published to Kafka BEFORE we return success to the user (acks=all). MirrorMaker 2 replicates events to EU and Asia. When US-East recovers, it replays Kafka from last committed offset. RPO = Kafka replication lag at time of failure (typically < 1 second).

PostgreSQL async replication to EU might have 500ms lag. US-East dies. Last 500ms of writes are gone. No log to replay. Unrecoverable. This is why Kafka is not just analytics infrastructure — it is your DR backbone.

US-East dies. EU detects this and promotes itself to write primary. US-East recovers (maybe it was a network blip). Now BOTH think they are primary. Both accept writes. Data diverges. You cannot automatically merge divergent writes. This is the worst failure mode in distributed systems.

Write service holds a lease in etcd with 30s TTL. Must renew every 10s. If US-East dies, lease expires after 30s. EU watches for lease expiry, races to acquire it. Only one region can hold the lease. The lease IS the primary writer token.

Every write includes the etcd lease version (a monotonically increasing number). Storage layer (PostgreSQL, Cassandra) rejects writes with a version number lower than the highest seen. US-East comes back zombie, tries to write with old version → rejected → cannot corrupt data.

etcd uses Raft consensus (simpler, better understood). ZooKeeper uses ZAB protocol. Both work. etcd is lighter, has a cleaner API, and is the Kubernetes default — most cloud infrastructure teams prefer it now. ZooKeeper has more history and battle-testing. Either is valid in an interview.

JSON Web Token. Three Base64-encoded parts: Header (algorithm), Payload (claims: userId, email, exp, iat), Signature (HMAC or RSA). The signature proves the token was issued by the IdP and hasn't been tampered with.

API Gateway validates JWT by verifying the signature using the IdP's public key (RS256 = RSA). No call to the Auth service per request. The public key is cached at the gateway. Massive throughput: validation is a CPU operation (< 1ms), not a network call.

HS256 uses a shared secret — any party with the secret can forge tokens. RS256 uses asymmetric keys — IdP signs with private key, everyone else verifies with public key. Only the IdP can issue tokens. RS256 is correct for multi-service architectures.

JWTs are stateless — you cannot "un-issue" one. If a user is banned, their JWT is still valid until expiry. Solutions: short expiry (15 min) + refresh tokens, or maintain a revocation list (sacrifices statelessness), or use opaque tokens with introspection (back to stateful).

Limits requests per user/IP per time window. Prevents abuse, DoS, and resource exhaustion. Different limits per tier (free vs pro vs enterprise).

Token bucket: bucket fills at constant rate. Each request consumes a token. Allows burst (up to bucket capacity). Leaky bucket: requests processed at fixed rate regardless of when they arrive. No burst allowed. Token bucket is more user-friendly.

Exact algorithm: store timestamp of every request in a sorted set (Redis ZADD). On each request: remove entries older than 1 minute (ZREMRANGEBYSCORE), count remaining (ZCARD). If count ≥ limit → reject. Exact but high memory: O(requests) per user.

If limit is 100/minute and window resets at :00, a user can send 100 at :59 and 100 at :01 — 200 requests in 2 seconds. The boundary allows 2× the limit. Sliding window solves this.

Server-Side Request Forgery: attacker creates a short URL pointing to an internal service (e.g., http://169.254.169.254/metadata — AWS instance metadata). When the server "validates" the URL by fetching it, it inadvertently exposes internal infrastructure.

Before storing a URL: resolve the hostname to IP. Check the IP against blocked ranges. Block: 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, 169.254.0.0/16 (metadata), 127.0.0.0/8 (localhost). Also: allowlist schemes (https only, block file://, ftp://).

Service Level Indicator. A specific metric: redirect success rate (%), p99 redirect latency (ms), URL creation success rate (%). Must be objective and measurable.

Service Level Objective. Internal target derived from SLIs: redirect success rate ≥ 99.9%, p99 redirect latency ≤ 50ms. No contractual obligation. Used to guide engineering decisions.

Service Level Agreement. Contractual promise: usually SLO minus a buffer (99.5% availability). Breaching SLA triggers compensation (credits, refunds). Never set SLA = SLO — you'll be paying credits constantly.

99.9% SLO = 0.1% allowed errors. Monthly: 0.1% × 30 × 24 × 60 = 43.2 minutes of allowed downtime. Error budget burn rate: if burning at 10× normal rate → page oncall before budget runs out. This is Google SRE's core concept.