Design a URL Shortening Service: Code Generation, Redirect Path, and Scaling
Company: xAI
Role: Software Engineer
Category: System Design
Difficulty: medium
Interview Round: Onsite
Design a URL shortening service. A user submits a long URL and gets back a short link; anyone who opens the short link is redirected to the original URL.
This is the whole interview: a 30-minute technical screen with no coding, so the design discussion itself is what is evaluated. Aim for a complete end-to-end design first, then go deep where it matters most.
```hint Start from the traffic shape
Estimate how often links are created versus opened, and let that ratio decide where you spend most of your design time.
```
```hint Where codes come from
Compare at least two ways of producing short codes, and ask what each one must coordinate across servers so that two long URLs never receive the same code.
```
### Constraints and Clarifications
- No code is expected. Requirements, estimates, APIs, a data model and an architecture are.
- The session lasts about 30 minutes, including requirements and questions.
### Clarifying Questions
- How many links are created per day, and how many redirects are served? What is the ratio of reads to writes?
- Can users choose custom aliases? Do links expire, and can they be deleted?
- Should the same long URL always map to the same short code, or get a new code each time it is submitted?
- Are click analytics required, and how fresh must they be?
- How short must the codes be, and which characters may they use?
- Must the service defend against abuse, such as spam or links to malware?
### What a Strong Answer Covers
- Scoped functional and non-functional requirements, with quick capacity estimates
- APIs for creating links and for redirecting, including the choice of HTTP redirect status
- A code-generation scheme that cannot produce collisions under concurrency, with the arithmetic for code length
- A data model and storage choice built around the redirect lookup
- A low-latency read path (caching, replication) and a write path that stays correct
- Scaling, failure handling and observability
- Time management: a complete design within 30 minutes
### Follow-up Questions
- One short link suddenly receives a flood of clicks. What happens in each layer, and what would you change?
- How would you add per-link click analytics without slowing down redirects?
- How would you support links that expire, and should expired codes ever be reused?
- How would you stop the service from being used to disguise malicious URLs?
Overview: A system design question asked as a 30-minute screen with no coding: design a URL shortening service that turns long URLs into short links and redirects visitors. It tests requirement scoping, capacity estimates, collision-free code generation, a fast read path, storage, scaling and failure handling.