Requirements
Functional Requirements:
- Create a short URL for a given long URL.
- Return the long URL associated with a given short URL.
Non-Functional Requirements:
- List the key non-functional requirements (eg low latency, scalability, reliability, etc.)...
API Design
The API should have an endpoint for posting the long URLs, then it generates the dynamic unique ID on the server. Basically creates a database record with it. So for instance when the server accepts the ABC URL, which is a full link, it should create a new record in the database with Slack or ID generated, and it should store the original URL. It should then return the created record to the server and server should respond with the information to the client. So the client sees the newly generated URL and should be able to copy it.
Another endpoint should be for processing the shorthand URLs. So when the client enters the shorthand URL, it should read the database record on the server for this URL. And it should redirect to the original URL.
An optional functionality here is maybe for logging the clicks or redirects and also another functionality worth considering is to have link removal. So when the client generates the link, it should also respond from the server with a URL that allows him to remove this shorthand URL from our data base. So it's not existing anymore.
High-Level Design
High level design is looking as shown on the diagram. nothing too complicated since it's enough like the client server and database. And the server can be a simple node.js. with postgresql or redis for even faster processing.
As for scalability, the Node.js server would be a perfect match here since it is asynchronous by nature and allows for very fast and concurrent requests at the same time, which makes the low latency feature optimization. As for scalability, it's pretty flexible since we can host this on lampdas, and then it scales automatically, or we can use V VPS and scale it by looking at the current demand.
As for reliability, we have to make sure that the database is having regular backups. It can be done when the server or the application has the lowest amount of users, like at 3 a.m. daily for instance
Detailed Component Design
I think a simple data structure would be something like original URL ID and shortened URL. The ID should be unique. The original URL don't have to be unique since many users can create URLs to different endpoints. And the shortened URL must be unique because only one URL must be created for specific ID or Slug.