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:

• Must scale near-infinitely

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

Shorten: user passes a long URL, and receives a short URL

Link: user goes to a short URL site and is re-directed to the long URL version

Upgrade: User upgrades to premium status to create more links. Integrated with Stripe or something for payments.

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.

The client interacts with the server which exposes the Shorten and Link endpoints. The server interacts with the relational database, which stores short URLs (primary keys) and their corresponding long URLs

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.

The database is a relational database which stores short URLs as keys and corresponding URLs as values. Each short URL is also linked to a "user" entity in the DB. Each user has an ID and hashed password. The shorten URL is blocked after a certain number of shorten URLs are created for the user, unless they upgrade to some premium status, then they can create more.

Short URL creation is done by simply hashing the URL via SHA256 and appending it to our site domain e.g. bit.ly/ae87e... the short domain is extended by one character length until it does not collide with any other short domains in our current database. We start with single character domains and grow overtime. We can track the current shortest possible domain to skip the first N iterations for hashes that are guaranteed to collide.