Loading...
- Shorten URL: The system can shorten a long URL to a short one
- Retrieve URL: The system can look up the long URL from the shortened one
- Uniqueness: A short URL always maps to exactly one long URL. The algorithm to generate a short URL from a long URL should handle collisions accordingly.
- High availability
- Low latency (<10-50 ms per request)
- Durability:
Let's assume:
Storage:
Define what APIs are expected from the system...
POST /api/shorten
Request payload:
{
longUrl: "https://...",
customAlias?: "myalias",
expireAt?: "2026-01-01"
}
Response: 201
Payload:
{
shortUrl: "https://short.com/abc123"
}
GET /:shortCode
If shortCode is found:
Response: 302
Location: {longUrl}
If shortCode is not found:
Response: 404
shortCode (str) (pk)
longUrl (str)
createdAt (str)
expiresAt (str)
API Gateway -- receives requests from clients. Redirects them to:
URL Shortening Service -- runs the shortUrl generation code
DB -- let's make it a NoSQL DB
URL Redirect Service -- looks up the shortUrl in the DB
Redis cache -- sits in front of the Redirect service, we can drastically reduce the load on the DB this way
(Analytics -- i have no idea what to do here)
Explain how the request flows from end to end in your high level design. Also you could draw a sequence diagram using the diagramming tool to enhance your explanation...
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...
Explain any trade offs you have made and why you made certain tech choices...
Try to discuss as many failure scenarios/bottlenecks as possible.
What are some future improvements you would make? How would you mitigate the failure scenario(s) you described above?