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

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 that takes in a long url writes it to DB and returns a short url

• this API implements write-back DB style writing to the cache first and flushing asynchronously later
• The API writes the long url, short url, date and time, and user and creates a hash ensuring security
• When writing we partition the DB by alphabetical order breaking htem up into sections to speed up writes and reads
• When actually writing hashes, we can implement linear probing to ensure there are no hash collisions
• When ensuring no URLs are already taken, we can conduct a binary search on the partitioned part of the DB
• When writing, we have a prepopulated DB to mitigate race conditions when 2 different users are attempting to write to the same URL short or long. We institue predicate locks for this

We have another API that takes in a short URL and returns a long URL

• It reads from the cache, and if it misses we add it to the cache implementing Least Recently Used principal

We can aslo implemnt URLs to ensure security and validation

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.

• We would have a backend relational DB like MySQL that has tables detailing the Long URLs, Short URLs, their audit information, and relationship mapping
• We can implement a tiered cache before writing to DB implementing a write-back style
• Next we before that we have a set of servers that can be horizontally scaled
• After that is a reverse proxy that acts as a load balancer directing traffic
• then there is the client that connects to the proxy over HTTPs

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.

• We would have a backend relational DB like MySQL that has tables detailing the Long URLs, Short URLs, their audit information, and relationship mapping
• We can implement a tiered cache before writing to DB implementing a write-back style
• Next we before that we have a set of servers that can be horizontally scaled
• After that is a reverse proxy that acts as a load balancer directing traffic it can utilize a robin algorithm adding servers when necessary
• then there is the client that connects to the proxy over HTTPs

API that takes in a long url writes it to DB and returns a short url

• this API implements write-back DB style writing to the cache first and flushing asynchronously later
• The API writes the long url, short url, date and time, and user and creates a hash ensuring security
• When writing we partition the DB by alphabetical order breaking htem up into sections to speed up writes and reads
• When actually writing hashes, we can implement linear probing to ensure there are no hash collisions
• When ensuring no URLs are already taken, we can conduct a binary search on the partitioned part of the DB
• When writing, we have a prepopulated DB to mitigate race conditions when 2 different users are attempting to write to the same URL short or long. We institue predicate locks for this

We have another API that takes in a short URL and returns a long URL

• It reads from the cache, and if it misses we add it to the cache implementing Least Recently Used principal
• We can aslo implemnt URLs to ensure security and validation