System requirements

Functional:

List functional requirements for the system (Ask the chat bot for hints if stuck.)...

shorten url

redirect url

tracking clicks

user management

expireation of short url

analytics dashbord

Non-Functional:

List non-functional requirements for the system...

latency

scalability

Capacity estimation

Estimate the scale of the system you are going to design...

Write QPS = 200

Read QPS = 20,000

daily storage = 4.4 GB

API design

Define what APIs are expected from the system...

1) Post /short/url

request

{

"user_id":"",

"url":""

}

response

{

"short_url":"",

"ttl":""

}

2) Get /short/url/{short_url}

request

{

"long_url":""

}

Database design

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...

URLMapping table:

High-level design

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...

1. Architecture Components

• Client: The front-end interface (web, mobile) through which users will interact with the service (e.g., input long URLs and receive short URLs).
• API Gateway: This acts as the gateway to the service, managing client requests, security (HTTPS), and load balancing among various service components.
• Shortening Service: Responsible for generating a short URL from a given long URL. It will handle the logic for creating unique keys and storing them in the database.
• Mapping Service: This service handles the redirection requests when a user requests access to a short URL, fetching the corresponding long URL from storage.
• Database: Stores the mappings between short URLs and long URLs, along with additional metadata like creation times and user information.
• Cache: Used to cache short URL to long URL mappings for rapid access and to reduce load on the database.
• Analytics Service (Optional): Gathers usage data to provide insights about clicks on short URLs (e.g., total redirects, geographic distribution).

2. High-Level Request Flow

To illustrate the interactions between these components, here’s a high-level flowchart representing the typical request flow:

3. Design Considerations

• Load Balancing: The API Gateway will balance requests between multiple instances of the Shortening and Mapping Services to manage load effectively.
• Caching Strategy: Implement a caching layer (like Redis) to store frequent mappings, which will drastically reduce the number of database accesses, especially under high load.
• Fault Tolerance: Deploy multiple instances of core services to ensure no single point of failure. Use health checks for monitoring the performance and quality of services.
• Scalability: Every component should be designed to scale horizontally to handle an increase in traffic. This might include the use of container orchestration services like Kubernetes.
• Security Measures: Implement proper security practices, such as input validation to prevent injection attacks and using HTTPS for secure communications.

4. Future Enhancements

• Custom URL Options: Allow users to request custom short URLs.
• Advanced Analytics: Develop an analytics dashboard for users to see click rates, demographics of users, and other related data.
• User Accounts: Implement user account management to help users keep track of their shortened URLs and the associated metrics.

Request flows

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...

1. Creating a Short URL:
   • The Client Application sends a request with a long URL to the API Gateway.
   • The API Gateway forwards this request to the Shortening Service.
   • The Shortening Service generates a short URL and stores the mapping in the Database.
   • Once the mapping is created, it returns the short URL to the API Gateway, which then responds to the Client with the newly created short URL.
2. Redirecting to a Long URL:
   • When a user tries to access a short URL, the Client sends this request to the API Gateway.
   • The API Gateway forwards the redirect request to the Mapping Service.
   • The Mapping Service first checks the Cache for the long URL associated with the short URL.
   • If the Cache has the mapping (Cache hit), it returns the long URL directly.
   • If the Cache misses, it queries the Database for the mapping.
   • After fetching the long URL from the Database, it returns that URL back to the API Gateway.
   • Finally, the API Gateway redirects the Client to the long URL.

Detailed component design

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...

• Client: The front-end interface (web, mobile) through which users will interact with the service (e.g., input long URLs and receive short URLs).
• API Gateway: This acts as the gateway to the service, managing client requests, security (HTTPS), and load balancing among various service components.
• Shortening Service: Responsible for generating a short URL from a given long URL. It will handle the logic for creating unique keys and storing them in the database.
• Mapping Service: This service handles the redirection requests when a user requests access to a short URL, fetching the corresponding long URL from storage.
• Database: Stores the mappings between short URLs and long URLs, along with additional metadata like creation times and user information.
• Cache: Used to cache short URL to long URL mappings for rapid access and to reduce load on the database.
• Analytics Service (Optional): Gathers usage data to provide insights about clicks on short URLs (e.g., total redirects, geographic distribution).

Trade offs/Tech choices

Explain any trade offs you have made and why you made certain tech choices...

Failure scenarios/bottlenecks

Try to discuss as many failure scenarios/bottlenecks as possible.

Future improvements

What are some future improvements you would make? How would you mitigate the failure scenario(s) you described above?