Loading...
the user should be able to get the short url.
the user should be redirected to the real url when using the short url
The user shoyld be able to share the short url
The user should be able to organize short urls by project
The redirection should not take more than 0.5s
Process of shortening the url should not exceed 3s
The application expects 100000 users per day the first year
99,9% of up time is expected.
Users
DAU = 10000 users. Stickiness of 20%. MAU = 50000 users.
Projection 5 years : DAU = 500000. Stickiness = 25%. MAU = 2000000.
Requests
Requests/day = 200000. Av QPS = 2.3. Peak QPS = 6.9.
Projection 5 years : Requests/day = 20000000. Av QPS = 231.5. Peak QPS = 1157.5
R/W
Read/write ratio = 40:1
Projection 5 years : Read/write ratio = 80:1
Storage
Write/day = 4878. Avg bytes/write = 1 KB.
Daily raw storage = 4878 KB. Yearly raw storage = 1780470 KB = 1.7 GB.
Index overhead = 40%. Yearly raw provisionned storage = 2.38 GB.
Projection 5 years : Yearly raw provisionned storage = 11.9 GB.
url
endpoint : api/v1/url/
method : post
Req body : { longurl, project (optional)}
Response : { status, shorturl, project}
endpoint : api/v1/url/id/{id}
method : get
Response : { status, shorturl, project, longurl}
endpoint : api/v1/url/project/{id}
method : get
Response : { status, [shorturls], project}
endpoint : api/v1/url/redirect/{shorturl}
method : get
Response : { status}
endpoint : api/v1/url/all
method : get
Response : { status, [shorturls]}
Describe the overall system architecture. Identify the main components needed to solve the problem end-to-end. Use the diagramming tool to create a block diagram.
Define the data model. Identify the main entities, their attributes, and relationships. Consider the choice of database type (SQL vs NoSQL) and justify your decision based on access patterns...
Deep dive into 2-3 key components. Explain how they work, how they scale, discuss tradeoffs, capacity, and any relevant algorithms or data structures.