Detailed component design

User->>API: User adds new link to shorten it

API->>DB: Saves new URL wtih new short ID

DB-->>API: New data inserted

API-->>User: Response with new shorten URL

User->>API: User uses shorten URL link

API->>Redis: API service check for cached data

Redis-->>API: Redis returns cached data in case it exists

API->>DB: If data does not exist in Redis, asks from DB

DB-->>API: Returns fresh data URL link

API-->>User: Returns response of linked URL with redirection

To avoid collisions on creating unique identifiers, we can lock the table/redis, add retry logic with exponential backoff. Use distributed locking mechanisms. If the ID generator is down, we can allow users to queue requests and process them once the generator is back online. Utilize a CDN to cache popular links at edge locations close to users. When a link is updated or disabled, ensure that the corresponding cache entries are purged or updated immediately. This can be achieved through TTL. TTL ensures that stale data is not served to users. By automatically removing old entries, TTL helps to manage memory usage effectively. Least Frequently Used eviction policy could be tried to use. For very hot IDs, consider using a dynamic caching strategy where you can increase the TTL (Time to Live) for these popular URLs. This means they stay in cache longer during peak traffic times, reducing the need to hit the database. Regularly monitor cache hit rates and eviction rates to adjust your policies as needed. This can help identify patterns in data access and optimize caching strategy. Determine optimal TTL values based on how frequently data changes and how critical it is for users to receive the latest information.

Use load balancers to distribute incoming requests evenly across multiple servers.

We can consider implementing a decentralized ID generation system, such as using a combination of timestamp-based identifiers and machine identifiers. This can help ensure that even if one generator fails, others can continue to produce unique IDs without collisions. For instance, we could use a combination of a timestamp, a machine identifier, and a sequence number to create unique IDs. This method allows multiple instances to generate IDs independently while minimizing the risk of duplication.

Database design

We will use NoSQL database, as we don't need to have structured tables, we just need to have key/value, so we will have one in cache, and one in DB for persistant data save.

Submissions

Displaying Solutions with Scores Ranging from 1 to 10

Submissions

Displaying Solutions with Scores Ranging from 1 to 10