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:

• Low latency
• Support multiple customers at the same time
• short URLs must be unique
• 1 short url for each long url

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

createShortUrl: // POST request

createShortUrlRequest: { longUrl: string, userId: string }

createShortUrlResponse: { shortUrl: string, longUrl: string, userId: string, error: Error | null }

getLongUrl // GET

getLongUrlRequest: { shortUrl: string }

getLongUrlResponse: { longUrl: string, shortUrl: string, userId: string, error: Error | null }

getShortUrl // GET

request: { longUrl: string, userId: string }

response: { shortUrl: string, longUrl: string, userId: string, error: Error | null }

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.

1. Frontend - customer interfaces with FE to trigger API call
2. API call (handled by APIG) takes in the request and redirects
3. BE logic takes in request
   1. For createShortUrl(), BE first checks if an existing tinyUrl exists. If it does, return url. Else create a new short url
   2. For other get calls, return get call
4. For createShortUrl(),
   1. create a UUID for the url if a short url doesn't already exist
   2. With a random string generator, create a string
   3. Store shortUrlId, shortUrl, longUrl, userId in DB
   4. return shortUrl

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.