# Design a Reliable URL Shortening Service Design a service that accepts a long URL and returns a short URL, then redirects short-code requests to the stored destination. Cover API design, code generation, storage, caching, expiration, abuse controls, availability, and scaling. State whether repeated submissions of the same destination should reuse a code and whether custom aliases are supported. Explain the redirect consistency users observe immediately after creation or deletion. ### Constraints & Assumptions - Redirect traffic is much larger than creation traffic. - Codes must be URL-safe and collisions must never silently overwrite another mapping. - Links may have optional expiration times. - Analytics can be asynchronous and must not delay redirects. ### Clarifying Questions to Ask - What traffic, latency, availability, and retention targets matter? - Are links editable, permanent, private, or scoped to an owner? - Must the service detect malicious destinations before redirecting? - Which redirect status code and cache behavior are required? ### What a Strong Answer Covers - Precise create, resolve, delete, and optional custom-alias APIs - Collision-safe ID or random-code generation - Durable key-value mapping, partitioning, cache policy, and negative-cache care - Expiration and deletion semantics across caches and replicas - Rate limiting, abuse review, observability, and asynchronous analytics ### Follow-up Questions - How would you migrate to a longer code space? - What happens when a popular link becomes a cache hot key? - How would you support region-local redirects after a control-plane outage? - How would you prevent enumeration of private links?