Authentication requirement: is URL creation anonymous or does it require a registered account? Anonymous creation is simpler but exposes the system to spam and abuse at scale. Authenticated creation enables per-user analytics, rate limiting by user identity, and custom alias namespace management. This choice affects whether the system needs an auth service, a user database, and session management — significant additional infrastructure.

This is a read-dominated system. 100:1 read-to-write ratio means caching strategy is the most important design decision. If you optimize writes but ignore reads, you have designed for 1% of the traffic.

The deduplication question changes the entire ID generation strategy. If the same long URL always maps to the same short URL, you need a lookup on write (expensive at scale). If each creation generates a new short URL regardless, write path is much simpler — just generate a unique ID.

SLA degradation behavior: what is the acceptable behavior when the system is degraded? Should it serve stale cached redirects rather than returning errors, or fail fast with 503? This determines whether the system should be designed for graceful degradation (serve from cache even if the database is down) or strict consistency (refuse to redirect if mapping cannot be verified). Most URL shorteners choose graceful degradation — a stale redirect is better than no redirect.

For This Case Study, Our Answers Are:

• Read:write ratio: 100:1 (read-dominated — caching is the primary design concern)
• Custom aliases: yes — must check uniqueness on write
• URL expiry: tiered — anonymous: 30 days, registered: 1 year, paid: permanent
• Deduplication: no — each creation generates a new short URL (simplifies write path)
• Analytics: yes — async, eventual consistency acceptable, separate store
• Geographic distribution: global users — CDN required, DB origin in one region initially
• Degradation behavior: graceful — serve stale cache rather than error
• Creation rate limit: yes — 10 URLs/minute per IP (anonymous), higher for authenticated
• Abuse scanning: yes — async scan at creation, interstitial for flagged URLs
• Redirect type: 301 with 24h max-age Cache-Control (not indefinite)

Cache warming on write: when a new short URL is created, immediately write it to Redis with the TTL policy (hot URLs: no TTL, cold URLs: 24-hour TTL based on access pattern). The first redirect to a new URL would otherwise be a cold miss — hitting Redis (miss), then the database. Pre-warming eliminates this first-request latency spike, which matters for newly created URLs that are immediately shared (social media posts, email campaigns). Cache warming costs one additional Redis write per URL creation — negligible compared to the benefit.

The key insight: 301 vs 302 redirect. A 301 (permanent) redirect lets browsers and CDNs cache the mapping indefinitely — reducing your server load by 70%+. A 302 (temporary) forces every request back to your server — useful only if you need to change the destination later or track every click. Most URL shorteners use 301 + async analytics.

The 301 cache invalidation problem: once a browser or CDN caches a 301 redirect, you cannot reliably update the destination. If a URL owner wants to change where their short URL points, or if a URL is flagged as malicious and needs to be deactivated, CDNs and browsers may continue serving the cached 301 for days or indefinitely. Mitigation: set a Cache-Control max-age on 301 responses (e.g., max-age=86400 for 24 hours) rather than allowing indefinite caching. This balances caching benefit with the ability to update or deactivate URLs within a reasonable timeframe. Twitter uses 302 specifically to retain this control — every click comes back to their servers.

Geographic database placement: CDN handles read latency globally (users get served from the nearest PoP). But on a cache miss, the request falls through to the origin database. If all database shards are in one region (us-east-1), a user in Tokyo who misses the CDN cache still experiences 150-200ms of round-trip latency to the database before receiving their redirect. At 5% cache miss rate with 4,000 reads/second, that is 200 requests/second hitting the origin from potentially far-away locations. Solutions: read replicas in multiple regions (replication lag is acceptable since URL mappings rarely change), or a globally distributed database (PlanetScale, CockroachDB). Most URL shorteners at moderate scale accept the origin latency for cache misses and invest in CDN cache hit rate rather than multi-region database replication.

Counter-based is simpler and collision-free. Hash-based gives natural deduplication. In practice, most production URL shorteners use counter-based (Snowflake/range allocation) because collision handling adds write-path complexity that isn't worth it at scale — especially when deduplication isn't a hard requirement.

Recommendation for new systems: use Snowflake IDs (or a compatible distributed ID generator like Twitter Snowflake, Instagram's ID generator, or ULID) with Base62 encoding. Implement hash-based generation only if deduplication is a stated product requirement from the business — not as a default choice. Hash-based deduplication adds write-path complexity and collision retry logic that is not worth the cost unless users explicitly expect the same URL to always produce the same short code.

Google URL Shortener (goo.gl) was shut down in 2019 after being available since 2009. Google's public reason: the service was increasingly used for spam and phishing, and the cost of abuse prevention outweighed the benefits of operating a free public URL shortener. All existing goo.gl URLs continued to redirect after shutdown but no new URLs could be created. This is instructive: abuse prevention is not an afterthought — it is a core operational cost that can determine whether a service is viable to run at all.

The URL shortener teaches: separate the hot path from everything else. The redirect (hot path) must be fast — CDN, cache, done. Analytics, abuse detection, expiry — all happen asynchronously. This pattern applies to every latency-sensitive system: payment confirmation pages, API responses, search results.

The most dangerous failures are cross-concern contamination. Analytics should never affect redirects. Cache expiry should never cause DB overload. Abuse detection should never slow down legitimate users. Isolate concerns — bulkhead pattern at system level.