Unique Link Generation: Issue a completely unique short link for every single request. This is ideal for tracking separate marketing campaigns for the same product, but it risks explosive database growth. To prevent this storage bloat, implementing a strict TTL (Time-To-Live) eviction policy to automatically purge stale links is mandatory.
When multiple requests come in for the exact same long URL, you face a distinct architectural trade-off: Deduplication: Save the mapping only once. This significantly optimizes storage capacity, but introduces an extra read check before every single write, causing minor write latency.
Therefore, tracking-focused companies must use 302 (Temporary Redirect). It tells the browser never to cache the link, forcing every single click to hit your servers for precise analytical tracking. To mitigate the heavy traffic load this introduces, we isolate our read/write paths by routing requests through a Redis cache cluster and distributed database read replicas.
There are two primary HTTP redirection statuses to consider: 301 and 302. 301 (Permanent Redirect) triggers aggressive browser caching. This is incredibly fast and removes almost all overhead from your infrastructure. However, because subsequent clicks bypass your servers entirely, marketers lose the ability to track ongoing user engagement data.
To solve this, we use the Twitter Snowflake algorithm. It generates highly unique, time-sorted 64-bit IDs directly in the application server's memory, combining absolute speed with optimized database indexing.
But for a large system, this approach fails. Centralized auto-increment IDs create a critical write bottleneck under heavy concurrent loads. On the other hand, using random UUIDs degrades database performance because unordered strings destroy sequential index efficiency, leading to random disk I/O.
For a small system (under 10,000 writes/day), keep it simple. Use the database's Auto-Increment ID and convert that integer to Base62 to create the short URL alias. Database sequential IDs are excellent because they are clustered indexes, making them highly optimized for fast disk lookups.
#system_design Let me work through how to design a URL shortener service. It is used for marketing tracking (to see where users click) and preventing link breakage when URLs are too long. When designing this, we must always clarify the system constraints first: - Is this specifically for marketing tracking? -What is the scale (how many write/read requests per day)?