System requirements

Functional:

1. Client should create an account first and need to login to generate a short URL for a long URL
2. 1 Billion reads per month
3. 100K writes per month
4. users should be redirected to long URL, when they hit the short URL in browser
5. Should provide analytics for client with metrics like how many hit for a particular url

Non-Functional:

1. Should have a redirect latency in milliseconds
2. System should have high availability of 99.9%
3. more reads than writes

Capacity estimation

1. Read requests per month = 10^9 ~= 385 req/sec 
2. Write requests per month = 10^5 = 0.03 req/sec ~= 2 req/min
3. A single microservice has a throughput of 100 req/sec, hence need 4 such services(4 replicas) to handle the reads and writes
4. Size of 1 record in DB = 100Bytes. since there are 10^5 write requests per month, then size of DB per month = 10^7 Bytes ~= 1 MB

API design

1. account_creation_service:
   1. /create_user_api(username,email) - return user_id
   2. /login_api(username/email, password) - redirect to home page
   3. /authenticate_user(user_id) - return true or false
2. url_generator_service:
   1. /generate_url_api(user_id, long_url) - return short_url
      • Receive the request
      • Authenticate the user
      • check the DB or Cache, if the long URL is already present
      • If already present return the short URL
      • If not, generate a new short URL and return the short URL
      • Edge cases:
3. url_redirection_service:(high traffic)

a. /redirect_api(short_url) - return long_url

• • • Receive the short url
    • Check the given short url in cache and check its expiry
    • If not present in cache, check in DB and check its expiry
    • If Success, return long url with http code as redirect(301 or 302)
    •  If failure - return appropriate error message.

Database design

1. Reason: need high availability, high scalability, read heavy, no concurrent read & write, hence no ACID properties, so choice is NoSQL DB
2. Choice - MongoDB/CouchBase

url_mapping

• long_url
• short_url(primary_key) - indexing for this column
• created_time
• user_id
• expiry_time

Analytics

• short_url
• accessed_ip
• Hit_time

High-level design

Request flows

Detailed component design

Dig deeper into 2-3 components and explain in detail how they work. For example, how well does each component scale? Any relevant algorithm or data structure you like to use for a component? Also you could draw a diagram using the diagramming tool to enhance your design...

Trade offs/Tech choices

My choice of tech for microservice would be some light weight framework with high i/o operation, like Go or FASTAPI or Node.js

Failure scenarios/bottlenecks

Try to discuss as many failure scenarios/bottlenecks as possible.

Future improvements

1. logging 
2. Error handling
3. Monitoring of service layer and DB layer
4. Load balancer
5. Cache: Improving performance with caching in each layer
6. Improving performance in DB layer with proper indexing, replication & sharding.
7. Indexing based on read criteria
8. Replication: master-slave architecture: one master with multiple replicas, read will happen from slave, write will happen to master and master will sync to all slave nodes.
9. The read will not happen as soon as the write happens, hence there is an enough sync time for slaves.
10.  Sharding the DB with consistent hashing