Requirements

Functional Requirements:

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

1. Create a shortened url given a url
2. redirect and fetch the url given the tiny url

Non-Functional Requirements:

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

1. Scale infinitely

Capacity Estimation

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

if we say that each character can be represented by a 100 different characters, then 11 characters has 1 trillion possible hashes and 12 has 10 trillion. Let's make it so that the string is 20 characters long to ensure there are no hash collisions then, we need 20 bytes to store that. 20 bytes for the hash and 80 bytes for the url is 100 bytes. 100 bytes at a million users is 0.1 GB so it is feasible to have this system be on a single instance.

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

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. Server - handle client requests and provide the appropriate url or
   1. On create, will create a hash for the user
      1. write-around-> the cache and the database are in sync. In this case, having multiple urls pointing to the same url is fine and we don't have harsh requirement of consistency across the DB and cache. Write around offers higher scalability than write-through. Write back cache doesn't make sense as this system is read heavy.
   2. On retrieve, will check if the cache has the value and it is still valid under the ttl.
      1. Can use LRU cache and, if unable to find in the cache, check the db and then update the cache (cache-aside)

to scale the system infinitely, we need to store items in the cache based on a key, in this case, we can use the target url as the key and index and then split the caches and the Databases on that key/index.

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

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.