Loading...
List functional requirements for the system (Ask the chat bot for hints if stuck.)...
User input the long URL and system need to return short url.
Whenever user enter short url. Redirect the user to original long url without any intermediate response
URL eviction policy is 1 year
List non-functional requirements for the system...
Response time should be less then 300ms.
high availability
Estimate the scale of the system you are going to design...
1000 request/sec is what we are expecting
Given the response time of 300ms.
1 request will take 300ms. then in 1 sec we can complete 10/3 ~= 3.33 request
means 3 requests will get complete by 1 thread in 1 sec.
so 1k request will need 1000/3 ~= 333 threads
Since our system is I/O bound. we can consider it will reduce wait time by 20%. i.e. 240ms for 1 request.
so, 1 sec it will complete 1000/240 ~= 4 request.
means 1k request will need 240 threads.
if 1 instance has 60 core. so we need 4 instance of application.
Database: We need to have total 240 db connection.
we are considering this as high read system.
Define what APIs are expected from the system...
create short url
Post:
baseurl/shortining?url=
return short url with status code 200
Get actual url
Get:
baseurl/redirect/
return status code 301 or 302 with redirect url
Defining the system data model early on will clarify how data will flow among different components of the system. Also, you could draw an ER diagram using the diagramming tool to enhance your design...
we will use NoSQL database. Because we do not have high ACID characteristic requirements.
document store : ShortURL
document will contain:
documentId
longActualUrl
ShortUrl
createAtTime
You should identify enough components that are needed to solve the actual problem from end to end. Also remember to draw a block diagram using the diagramming tool to augment your design. If you are unfamiliar with the tool, you can simply describe your design to the chat bot and ask it to generate a starter diagram for you to modify...
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...
API Gateway: Will be responsible for routing as well as load balancing. We have service discovery where each instance on start register itself with service discovery.
API gateway will query service discovery to find the active instance ip address and port.
Each service periodically send heartbeat to service discovery and API gateway will will query and cache data of active srevice from service discovery.
Application: Application will query cache. If present it will return.
If not present it will query database
data from database will be saved to cache.
cache eviction policy would be TTL after expiry it will evict the data.
Database: we have read database and write database.
and Change data capture.
Change data capture react to changes in write database send an event. that event is subscribed and update the read database.
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?
We typically need 4 instances of application. we are currently using 1 read, write database. we can think of have more replicas in future. we can think of sharding, partitioning in db