System requirements

Functional:

1. Shorten a given long URL to a shorter one.
2. Users should be able to specify a specific alias if possible, otherwise randomly generated.
3. The short URL when entered should be able to redirect to the long URL.

Non-Functional:

1. The system should track the number of times the short URL is used to access the long URL.
2. Highly available (all the time)
3. Scalable to billions of URLs

Capacity estimation

1. I want to assume 100K users a day, 3 clicks a day so 300k redirects.
2. 4 requests a second

API design

1. CRUD operations

Database design

1. key-value store where key is the generated URL and value is the long URL - any DB system suffices.

High-level design

Request flows

1. Client POST at /shorten - writes mapping to DB and returns the shortened URL

Detailed component design

Dig deeper into 2-3 components and explain in detail how they work. For example, how well does each component scale? Any relevant algorithm or data structure you like to use for a component? Also you could draw a diagram using the diagramming tool to enhance your design...

Trade offs/Tech choices

NoSQL KV store preferred, faster, scales out regardless of operational complexity.

Failure scenarios/bottlenecks

Higher operational complexity, DB writes unavailable, data center outage

Future improvements

• analytics board
• rate limiting, abuse detection