Requirements
Functional Requirements:
- Create a short URL for a given long URL.
- Return the long URL associated with a given short URL.
- remove/update URL
Non-Functional Requirements:
- List the key non-functional requirements (eg low latency, scalability, reliability, etc.)...
Low Latency, Graceful Degradation, horizontal Scalability, Availability, Reliability. expiration. uniqueness,
100 new links per second, 10,000 redirects per second.
Analytics. Like geography, timestamps, IPs maybe. Devices.
No custom aliases.
No editing, Only add, delete.
eventual consistency.
Malware verification.
If different users shorten the same URL, they get different short links.
Link for extending/deleting URL Is sent to email.
Base64 characters. 8 characters per URL.
Storage time five years, can be extended by Link for extending
anti-bot protection for link creation
Delays for next link creation for the same email / ip / device
API Design
Define the APIs expected from the system. This is your chance to analyze and define the read and write paths so that you can come up with the high-level design...
/api/v1/checkurl To check a long URL for malware or phishing or whatever else, if it aligns with our rules. Receives long URL. Returns JSON with short lifeterm validation token. Token must be created with JWT or something similar.
/api/v1/addurl Add new URL. Gets validation token and long URL. Returns JSON with short URL.
/api/v1/geturl Get URL for short URL. Short version is /shortURL
Get short URLRedirects 302 to long URL. (301 Will eliminate analytics)
/api/v1/manageurl Delete URL or update its availability. Get short URL, management_token and command (update/delete)Returns result of execution.
High-Level Design
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.
/api/v1/addurl
Load Balancer -
web server -
(pre-generated short urls)(+ rate limiter)
validation service -
(verifies if long url passed verification - JWT)
queue -
(send email)(add to DB)
database worker -
database
/api/v1/geturl
Load Balancer (Health Checks) -
web server -
(async save analytics)
cache -
database
/api/v1/checkurl
Load Balancer (Health Checks) -
web server (Short Polling) -
validation queue -
validation worker -
JWT generator
/api/v1/manageurl
Load Balancer (Health Checks) -
web server - (verify token)(invalidate cache)
queue -
database worker - (update/delete record)(soft delete)
database
Detailed Component Design
Deep dive into 2-3 key components. Explain how they work, how they scale, discuss tradeoffs, capacity, and any relevant algorithms or data structures.
Add URL component
There is an input area. A person enters the URL. There must be some anti-bot system On the client side. Verification of the URL, 200 ok, security, malware. And then after all verification is complete, we return shortened version of URL to the user.
the URL user provided is sent to server To fast API endpoint. This server sends the response that URL is acquired for analysis And puts URL into queue. Then URL from queue is sent to module, which does the analysis. A module sends a response about analysis results back to server, and server sends response back to frontend. If analysis is okay, so server sends shortened URL. If analysis is somehow failed, server sends "fail" response to frontend.
While waiting, frontend might show some kind of ads or something.
A new URL is written to SQL database.
So, there might be, must be a module that responsible for front-end interaction, module responsible for Security and availability and probably other verifications. Also a module responsible for storage and caching.
Get URL component.
The server gets the short URL, fetches needed long URL from Module responsible for storage.
And then it sends http 302 with a long URL.
Or possibly it shows advertising screen with JavaScript redirect after advertising time is over, With long URL as well. Must have some anti-DDoS protection.