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:

• Availability: Higher availability of short to long url query comparing to creation.
• Latency: Lower latency on short to long url query. Average latency on mapping creation.
• Scalability: High traffic on short to long url query comparing to creation.

API Design

Concept (data)

shortUrl

• id
• code (The shorten url. For simplicity, we can use string id as code)
• destination (the origin long url)
• Owner
• LastUpdatedBy
• LastUdpatedDate
• CreatedDate

RESTful API - api/v1/

1. POST shortUrls/
2. GET shortUrls/{id} // id is equal to shortUrl
3. GET shortUrls/by-code/{code} // when id cannot be shortUrl
4. GET shortUrls/{id}?fields=destination
5. PATCH shortUrls/{id}
6. DELETE shortUrls/{id}

High-Level Design

• The long url -> short url mapping is stored in a database.
• There is an API layer responsible for the operation of the mappings.
• To reduce latency, we can have a router in front of the API to route users to the closer geo-API endpoint. Then we can add a cache layer between API and database for read operation.
• Cache will expire based on TTL.
• As for database, since we cannot afford duplicated record of the map and there seems no reasonable sharding algorithm (urls are usually global accessible), we will use a single database instance as a starting point.

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.

Router: it will route user query based on the request operation type. For read operation, it will route the user to the nearest API endpoint based on geo location. For write operation, it will route the request to write API endpoint.

Read API: it's backup by a microservice (so it can scale). It's a stateless service where it will get the map from cache, if no cache hit, then query database directly and update the cache. For better query experience, we can add GraphQL support in the API.

Write API: it's backup by a microservice (for scale) as a stateless service. It will operate database operation per request.

Map cache: The map cache can be any cache service. it can be in-memory cache or cache with storage (e.g. Redis). Cache records use TTL to balance between cache hit and legacy record.

Database: For this case, it might not make sense to use relational database since we don't have complex data structure. We can use common document db to store the url map records. Based on the query, we will have to turn on indexing of id/code. The database should have replica for data recovery.