TinyURL — Counter-Based (Base62)

The counter-based URL shortener is the standard production answer to the TinyURL interview question. It addresses every bottleneck identified in the naive variant: a Redis cache absorbs 95% of redirect reads, an atomic counter eliminates collision risk during ID generation, a load balancer distributes traffic across multiple service pods, and Base62 encoding produces compact 7-character short codes from sequential integers.

The core insight is the 100:1 read-to-write ratio. URL shorteners are massively read-heavy — for every URL created, it is redirected through 100 or more times. The naive variant forces every one of those reads through PostgreSQL. Adding a Redis cache changes the economics dramatically: at a 95% cache hit rate, only 5% of reads reach the database. At 10K redirect RPS, that means Redis handles 9,500 reads/sec (~2ms each) while PostgreSQL handles only 500 reads/sec (~10ms each). Database utilization drops from 95% to under 15%.

ID generation uses Redis INCR to maintain a global atomic counter. Each new URL gets the next integer (e.g., 1000001), which is Base62-encoded to produce a 7-character short code (e.g., "4c92"→"4c92" in Base62). This guarantees uniqueness without collision checks — every integer maps to a unique Base62 string, and INCR is atomic. The trade-off is that sequential IDs are guessable: observing two short codes reveals the total URL count between their creation times. For most use cases this is acceptable; for privacy-sensitive applications, a bit-shuffle or XOR mask can obscure the sequence.

This template introduces the API Gateway and Load Balancer layers. The API Gateway handles JWT authentication and rate limiting, protecting the service tier from abuse. The ALB distributes traffic across 6 UrlService pods using round-robin, providing horizontal scalability and redundancy — losing one pod reduces capacity by 17% instead of 100%.

The comparison with the naive variant is instructive. Same workload, dramatically different results: p99 redirect latency drops from 50ms (DB-bound) to 12ms (cache-bound), maximum throughput increases from 500 RPS to 20K+ RPS, and database utilization drops from 95% to 15%. The only additions are a cache, a counter, a load balancer, and a gateway — each solving a specific bottleneck identified in the naive approach.

The counter-based URL shortener adds three components to the naive architecture: an API Gateway for authentication and rate limiting, a Load Balancer for traffic distribution, and a Redis Cache that serves dual duty as both the read cache and the atomic counter for ID generation.

All traffic enters through the API Gateway (Amazon API Gateway REST), which validates JWT tokens (~3ms), enforces rate limits (30K RPS cap with headroom), and routes requests to the ALB. The Gateway adds security without burdening the service tier. The ALB distributes requests across 6 UrlService pods using round-robin — stateless routing since no session affinity is needed.

The UrlService (6 pods, 100 threads each) handles both URL creation and redirect logic. For URL creation (POST /api/v1/shorten), the service calls Redis INCR on a global counter key to get the next sequential integer, Base62-encodes it into a 7-character short code, writes the mapping to PostgreSQL (durable storage), and writes it to Redis (cache population). For redirect reads (GET /api/v1/redirect/{code}), the service checks Redis first — at a 95% hit rate, most redirects are served from cache in ~2ms. On cache miss (~5% of reads), the service falls back to PostgreSQL (~10ms indexed read) and writes the result back to Redis for future requests.

Redis serves dual purpose: (1) the INCR command maintains the global atomic counter for ID generation — O(1), sub-millisecond, and guaranteed unique; (2) the cache-aside pattern stores URL mappings (key: url:{short_code}, value: original_url) with 24-hour TTL and LRU eviction. URL mappings are immutable after creation, making cache invalidation trivial — there is none. The 95% hit rate emerges naturally from the Zipfian access pattern: a small fraction of URLs (viral links) receive the vast majority of redirect traffic, and these stay hot in cache.

PostgreSQL serves as the durable store with 2 read replicas. At 95% cache hit rate, only ~500 reads/sec reach the database (5% of 10K redirect RPS), plus ~2K writes/sec for URL creation. The database operates comfortably at 15-20% utilization — a dramatic improvement from the naive variant's 95%.

The architecture handles 20K+ RPS at peak with comfortable headroom at every layer. The service tier (6 pods x 100 threads = 600 concurrent slots at 5ms processing time) sustains ~120K RPS. The ALB is rated for 50K RPS. Redis handles 100K+ operations/sec. The bottleneck at extreme scale is the atomic counter — Redis INCR is a single-point contention at 2K writes/sec, well within Redis capacity but would require counter sharding at 100K+ writes/sec.

Horizontal scaling at the service tier: ECS auto-scaling adds pods based on CPU utilization (target: 60%) or ALB request count. Redis can be scaled vertically (larger node type) or horizontally (Redis Cluster with more shards). PostgreSQL scales reads via additional read replicas and writes via vertical scaling. The scaling ceiling is approximately 20K RPS, limited by: (1) the atomic counter's single-point contention at high write rates, and (2) the single Redis cluster's memory capacity for the URL cache. Beyond 20K RPS, upgrade to the Production variant (v3) with CDN, ZooKeeper range allocation, and sharded databases.

Key metrics to monitor: Redis cache hit rate (target: >90%, alert at <85%), Redis memory utilization (alert at 80%), Redis INCR counter value (informational — track growth rate), PostgreSQL active connections (alert at 160/200), DB replication lag (alert at >10ms), ALB request count and error rate, API Gateway 4xx/5xx rates, service pod CPU and memory utilization, and end-to-end redirect latency p99. The most important single metric is cache hit rate — a drop from 95% to 80% doubles database load. Set up a correlation dashboard showing cache hit rate vs. DB utilization vs. redirect latency to catch cascading degradation early.

Monthly infrastructure cost at moderate traffic (10K RPS): API Gateway (~$35 for 26B requests/month), ALB (~$20 + $8/million requests), 6x ECS Fargate pods (2 vCPU, 4 GB each, ~$360/month), ElastiCache Redis (cache.r7g.large 2-node, ~$200/month), RDS PostgreSQL primary + 2 read replicas (~$360/month). Total: approximately $400-450/month. Compared to the naive variant at $180/month, you get 40x the throughput (20K vs 500 RPS) for 2.5x the cost. Cost per 1M requests: ~$0.60 (vs $12.00 for naive). This is the sweet spot for most production URL shorteners — simple enough to operate, cost-effective up to 20K RPS.

The API Gateway adds JWT authentication, preventing anonymous abuse. Rate limiting (30K RPS cap) protects against DDoS and bulk URL creation. Sequential Base62 short codes are guessable — an attacker can enumerate URLs by incrementing the counter. Mitigations: (1) apply a bit-shuffle to the counter before Base62 encoding, (2) require authentication for URL creation, (3) implement URL scanning to block malicious redirect targets (phishing, malware). Redis should be deployed in a private subnet with security group rules limiting access to the service tier only. PostgreSQL credentials should be stored in AWS Secrets Manager and rotated on a schedule.

Rolling deployment via ECS service update. The ALB drains connections from old tasks (30-second drain period) before terminating them. With 6 pods, a rolling update replaces one pod at a time, maintaining 83% capacity throughout. Blue/green deployment is supported via ALB target group switching for zero-downtime releases. Database migrations run before code deployment using a separate migration task. Redis cache is populated on demand (cache-aside), so no pre-warming is needed after deployment — the first requests after deploy will have cache misses that resolve on subsequent access.