Design a URL-Shortening Service

Design a URL-shortening service. Explain how a long URL receives a short identifier, how redirects are served, and how the service preserves correct mappings as usage grows. ### Constraints Traffic, storage volume, availability targets, expiration, custom aliases, and analytics are not specified. Clarify them before selecting a design. Use a hypothetical workload only if you label it; no particular scale or redirect status is required. ### Clarifying Questions - Can the same long URL receive several short links, and can users choose custom aliases? - Are mappings immutable, expiring, or editable? - What redirect semantics and abuse controls are required? - Is multi-region operation necessary, and how quickly must a new link be usable everywhere? ```hint Separate identifier creation from lookup Generating an identifier is only one part of the design; collision handling and durable mapping availability determine whether it works reliably. ``` ### What a Strong Answer Covers - Creation and redirect APIs, identifier uniqueness, and durable mapping storage. - Caching, expiration, collision or allocation policy, and read-path scaling. - Update semantics, misuse controls, and observability tied to stated requirements. ### Follow-up Questions - How would you prevent two creators from claiming the same custom alias? - How would an expired mapping be removed consistently from caches?