Design a short-link service: code generation, redirects, scaling and abuse controls

Design a link-shortening service similar to Bitly. A user submits a long web address and receives a short link; anyone who opens the short link is sent on to the original page. Explain what the product must do, how you would build it, and the main trade-offs in your design. ```hint Let traffic shape the design People open existing short links far more often than they create new ones. Decide what that imbalance means for how you generate codes, where you keep the mapping and how you keep the redirect fast. ``` ### Clarifying Questions - Who is the service for: anyone on the web for free, or businesses that need branded links, link management and click analytics? - Should users be able to choose their own short codes, and can links expire or be pointed at a new destination after creation? - What scale should the design handle: how many new links per day, and how many clicks per second at peak? - Is click analytics part of the first version, and how fresh does it need to be? ### What a Strong Answer Covers - Functional and non-functional requirements, with users and scope settled before the architecture. - A short-code scheme (length, alphabet, generation method) and how it avoids collisions and guessable sequences. - A data model, the create and redirect APIs, and the choice of redirect status code with its effect on analytics and caching. - Scaling the read path with caching and replication, plus availability targets and failure handling. - Abuse prevention (spam, phishing, malware) and the product and system metrics to track. ### Follow-up Questions - A link goes viral and receives millions of clicks in a few minutes. Where does the load land, and what keeps redirects fast? - How would you stop the service from being used to disguise phishing and malware links without slowing down legitimate users? - How would you add per-link click analytics without adding latency to the redirect?