Loading...
User should be able to input a large URL and receive and shortened alias in return.
Alias should be optionally inputted by the user.
Links should have an optional expiry date.
Click analytics should be tracked
Authorization checks
Redirecting to another URL should have minimal latency
Should be scalable (10000 URL shortenings per second)
High availability (99.999% uptime)
Load: 50:1 read/write ratio. 10000 new urls/sec. 500000 read URLs/sec. 10000 analytics requests/second
Storage: 5MB/sec, 400GB/day, 1.2 TB a month of storage, 30TB for 2 years of storage
Bandwidth: For write operations 5MB/sec, For read 250MB/sec For analytics
resources: 5200000ms/sec processing time, 5200 cores needed
createURL(devAPIKey, originalURL, expiryDate=None)
getURL(devAPIKey, url)
getURLAnalytics(devAPIKey, url)
30TB for 2 years storage
Read heavy
No relationships will be required
NoSQL - wide column database, Cassandra
classDiagram
TINY_URL <|-- USER
TINY_URL: +URL_ID_PK
TINY_URL: +ORIGINAL_URL_TXT
TINY_URL: +TINY_URL_TXT
TINY_URL: +EXPIRY_DATE_DT
TINY_URL: +USER_ID_FK
TINY_URL: +CLICKS_NB
class USER{
+USER_ID_PK
+NAME_TXT
+DEV_KEY
}
flowchart TD
B[client] --> I[LB] --> C{server}
C --> E{Create URL service}
E{Create URL service} --> G[Database] --> H[Database replica]
C --> K[LB] --> D[Database]
C --> M[LB] --> J[Cache]
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?