Requirements

Functional Requirements:

List the key functional requirements for the system (Ask the AI for hints if stuck)...

1. users should be able to upload a long url and get back a shorter url from tiny url
2. tiny url are proxy links which can be shared with other users, any user given a tiny url should be able to be redirected to the original url
3. 1 million DAU

Non-Functional Requirements:

List the key non-functional requirements (performance, scalability, reliability, etc.)...

1. no user authentication is required.
2. the links may be eventually consistent
3. the links will be read heavy
4. highly available
5. low redirect latency
6. scale horizontally

Capacity Estimation

Estimate the scale of the system. Consider daily active users, read/write ratio, storage requirements, bandwidth, and any relevant QPS calculations...

lets say 1million users -> each user may use 5 links in a day. 5 million requests per week -> ~800k queries per day. 30k queries per hour.

each user may make 1 link per week.

1:5 write/read.

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

1. create link,
   1. PUT/POST
   2. Request
      1. link
      2. jwt
   3. response
      1. tinyurl link (tiny url domain + id)
2. redirect
   1. GET
   2. request
      1. tinyurl id
   3. response
      1. original link and redirect.
3. delete (if we want to add link management and ownership, each user can own up to 100 links for a soft limit)
   1. tiny url id
   2. jwt
4. login
   1. request
      1. credentials
   2. response
      1. jwt
5. logout
   1. request
      1. jwt
   2. response
      1. success boolean
6. get links
   1. GET
   2. Request
      1. jwt
   3. response
      1. list of tiny urlids and original ids.

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. authentication service
2. URL Management service (create, delete, user login, logout )
   1. connects to authentication login
   2. connectes to nosql both tables
3. Redirect URL Service
   1. serves public traffic for all redirects.
   2. connects to nosql table only.
4. NoSql service
   1. User table, for each user data
      1. email
      2. hashed password
      3. URLs Map <string, string>
         1. tiny Url ids
   2. tiny url table
      1. tinyUrlid: tiny url id, serially generated to avoid collision
      2. original link
5. Distributed cache(redis or memcached)
   1. LRU(keeps the hot links in the cache and evicts the least popular)
      1. keeps 80% of the users happy and redirects fast.
6. circuit breakers to stop clients from hitting the service particularly the url management service and url service on high errors.
7. exponential fall back
8. single flighting, to avoid a thundering heard we can add a distributed locks from getting the same, to implement some sort of single flighting. for each instance

Database Design

Define the data model. Identify the main entities, their attributes, and relationships. Consider the choice of database type (SQL vs NoSQL) and justify your decision based on access patterns...

for this particular problem we can approach it with a nosql because the reads and writes are very consitent.

NoSql service

1. User table, for each user data
   1. fields
      1. email
      2. hashed password
      3. URLs Map <string, string>
         1. tiny Url ids
2. tiny url table
   1. fields
      1. tinyUrlid: tiny url id, serially generated to avoid collision
      2. original link

i have considered other table improvements but i dont think there is a simple way to boost the read write path as the read path is pretty versatile and unpredictable, no sharding is possible here.

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.

1. the cache
   1. implementation
      1. the cache will be implemented as a lazy load, where on a redirect we will first attempt to get from cache
      2. if not in cache fetch from db and store in cache
      3. return
   2. Cache strategy:
      1. eviction policy;
         1. Least recently used
      2. cache strategy
         1. cache aside, lazy load
      3. ttl strategy
         1. touch on read to avoid expiration.
   3. alternatives considered
      1. most ideal solution. there is no guarantee on a user create a new link the link will be shared and utlized immediately, no need to write aside.
      2. cache ahead is also speculative and not performant
2. User management will have application level checks on user limitations such as create and deletions and jwt checks to check user validity to ensure on the real owner can manage the links.
3. ID generation
   1. Since we are not using SQL there is no acid and we are left to generate the id manually
   2. create a time based id generator by encoding the current service task arn and count in window
   3. ensures the id is consistent and does not clash in a distributed system