System requirements

Functional:

1. Long to short url
2. Multiple short url for a long ?
3. Read-to-write ratio per month or per day? Per day 1(write):100(read)
4. Profile for client
5. Analytics to client

Non-Functional:

1. Latency part - as low as possible. - milli sec
2. Availability - 99.9%

system...

Capacity estimation

Estimate the scale of the system you are going to design...

Read req - per month = ? = per sec 

Write req - per month = ? = per sec

Throughput of a particular microservice -?

Size of 1 record - in mapping DB, analytics DB - * no of records per month

Storage capacity need - per month - per year

No of cache DB required - size of each cache DB

API design

1. account_creation_service:(minimum load only)
2. /create_user_api
3. /login_api

1. url_generator_service:(minimum load only)
2. /generate_url_api

• Receive the req
• Authenticate the user
• Old long url
  • use prev short url - Return the short url
  • generate new short url
• New long url - Generate a unique short string
• If new short url - Map into the long url in DB 
• Return the short url

c) url_redirection_service:(high traffic) - should scale

1. /redirect_api
   • Receive the short url
   • Check long url in cache, check expiry
   • Check long url DB, check expiry
   • If Success, return long url with http code as redirect(301 or 302)
   •   or failure msg

APIs are expected from the system...

Database design

1. Reason: need high availability, high scalability, read heavy, no concurrent read & write, hence no ACID properties, so my decision is to go with 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