Short-Link Service Design: Code Hashing, Collision Handling, and Read-Heavy Scaling

You are in the system design round of a senior software engineer loop. Design a URL shortening service. A user submits a long URL and gets back a short link, and anyone who opens the short link is forwarded to the original address. The interviewer will let you scope the problem and sketch the architecture, then spend most of the session on three areas: how short codes are produced, how collisions are prevented or resolved, and how the service scales on both the link-creation path and the redirect path. State your trade-offs explicitly. The interviewer will push back on your choices. ### Constraints and Clarifications - The prompt is the classic open version with no product-specific twist. The scope below is the standard one and is stated as an assumption. - Core features: create a short link for a long URL, and redirect a short link to its original URL. Custom aliases, expiration and click analytics have not been decided, so ask about them. - For as long as a link exists, its short code must map to exactly one long URL. - Assume redirects far outnumber link creations. No traffic figures are given, so make your own estimates and state them. ### Clarifying Questions - If the same long URL is submitted twice, should it get the same short code or a new one? Does the answer change when two different users submit it? - Are custom aliases and expiring links required? Can a code ever be reused after its link expires? - How short do codes need to be? Is it acceptable for codes to be guessable or sequential? - Does the business need per-click analytics? The answer decides how much redirect caching outside your own servers is acceptable. - What latency and availability targets apply to the redirect path, and how do they compare with the create path? ### Part 1 — Core design Lay out the functional and non-functional requirements, a rough capacity estimate, the API, the data model, and the end-to-end flows for creating a link and for resolving one. ```hint Separate the two paths Creating links and resolving them differ in volume and in latency needs. Sketch each one separately before you choose storage. ``` #### What This Part Should Cover - Requirements with a stated read-to-write ratio and a storage estimate - An API for creating a link and for resolving a code, including the HTTP response a redirect returns - A data model for the code-to-URL mapping, and a storage choice justified by the access pattern - The full create and redirect flows ### Part 2 — Short-code generation and collisions Explain how a request becomes a short code. Compare at least two strategies, such as hashing the long URL versus assigning codes from a counter or a pre-generated pool. For each one, explain how collisions are detected or ruled out when many application servers create links at the same moment. ```hint Count the code space Work out how many distinct codes a given length and alphabet allow, and what happens when a long hash is cut down to that length. ``` ```hint Two writers, one code Ask what actually guarantees uniqueness when two servers choose the same code in the same millisecond. ``` #### What This Part Should Cover - Code length and alphabet sized against the number of links expected over the service's lifetime - Trade-offs between hash-based, counter-based and pre-generated schemes - A collision mechanism that stays correct with concurrent writers - Behavior for duplicate long URLs, custom aliases and guessable codes ### Part 3 — Scaling reads and writes Traffic grows by orders of magnitude, almost all of it on redirects, and a few links go viral. Explain how you scale the redirect path and the create path, where the caches sit, how the mapping data is partitioned and replicated, and what happens when a cache node or a database replica fails. ```hint Follow one viral link Trace repeated requests for a single hot code from the client inward, and decide which layer should absorb them. ``` #### What This Part Should Cover - Caching layers for redirects, and how cached entries expire or get invalidated - The partitioning key and replication scheme for the mapping store - Producing codes at scale without a single coordination bottleneck - Failure handling, and the metrics that show the redirect path is healthy ### What a Strong Answer Covers - Scopes the problem deliberately and bases component choices on stated estimates - Makes each trade-off explicit: hashing versus counters, permanent versus temporary redirects, cache freshness versus load - Proves that codes stay unique under concurrency instead of assuming it - Designs for the read-heavy, skewed traffic pattern - Answers pushback by reasoning from the requirements instead of restating the design ### Follow-up Questions - How would you add click analytics without adding latency to the redirect? - How would you support expiring links? Is it ever safe to give an expired code to a new URL? - How would you stop the service from being used to disguise phishing or malware links? - How would you run the service in several regions while keeping codes unique and redirects fast?