Requirements

Functional Requirements:

• Create a short URL for a given long URL.
• Return the long URL associated with a given short URL.

Non-Functional Requirements:

• List the key non-functional requirements (eg low latency, scalability, reliability, etc.)

1. Low Latency (Critical)

• Redirect should be < 10ms
• Achieved via:
  • CDN/Edge caching (serve hot URLs directly)
  • Redis cache-first lookup
  • No API Gateway in redirect path

2. High Throughput

• System should handle millions of redirects/sec
• Achieved via:
  • Stateless redirect service (horizontal scaling)
  • Load balancer + CDN
  • Async analytics via Kafka (non-blocking)

3. Scalability

Horizontal Scaling

• Scale:
  • Redirect service (read-heavy)
  • Shortener service (write path)
• Use auto-scaling groups

Database Scaling

• SQL:
  • Read replicas for redirect
  • Sharding by short_code for large scale
• Redis:
  • Cluster mode for high traffic

4. High Availability

• Multi-region deployment:
  • Services + DB replicated across regions
• Failover:
  • Traffic routed via DNS/CDN to healthy region
• Redis + DB replication

5. Reliability

• No data loss:
  • DB is source of truth
• Retry mechanisms for:
  • Kafka producers
  • DB writes
• Idempotent URL creation (optional)

6. Consistency

• Strong consistency for writes (URL creation)
• Eventual consistency for analytics

7. Unique ID Generation

• Must guarantee globally unique short codes
• Options:
  • Base62 encoding of ID
  • Snowflake (distributed ID generation)
• Avoid collisions at scale

8. Caching Strategy

• Cache-aside (read path)
• Write-through (on create)
• CDN caches 301/302 redirects

9. Fault Tolerance

• Service failures handled via:
  • Retry + fallback (DB if Redis fails)
• Circuit breakers for downstream services

10. Security & Abuse Protection

• Rate limiting (edge level)
• URL validation (malicious links)
• Optional:
  • Spam detection
  • Blacklisting

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

shotren url:- api/v1/url/short

(when user hit this this api end-point it goes to a shorten service which uses a id genration service which handle a unique horten code fro the sepecific url nad that process is being streamed to our analytic service to store certain meta data and intiat a doc of the url in mongod

redirect url:- api/v1/url/redirect {

when user call this api it oes bia a rate limiter then load babalancer which redirect thie call to redirect ervice where redirect service looks in redis if yes redirect or else look n databse and fetch and store in redis for further call delay avoiding aldo this have been connected to a async kafka to update the analytics like (clicks, location etc) in analytic for specific url

}

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.

so we've built a url shortner saas

when user hit the application or any of our api endpoint ->goes to the cdn/edge server near to their region (if redirect is then send to redirect_service from there only)

now all these request go via a rate limiter->loadbalancer->api gateway

rate limiter handles the no of request from a ip in a particular time period

load balancer handles the distributing the load /traffic to servers or gateway where capacity is not exceeded

then in api gateway the authentication, authorization and routing or creating proxy to other in micro services is don't to protect the system from being exposed to public

if api/v1/url/create

this have user token in header, long_url

which goes to shortener_Service which handles the the creating a shirt id for specific url

it uses a id_geberation_Service which is responsible for unique id generation at large scale making the system reliable and avoiind duplicates id

thenoption data is streamed to kafka to be stored in mongodb for other anlaytics purpose

also the reason we using kafka to handle the high traffic for handeling analytic service so no data is loss and service doesn't get lot of load which helps to go other services without hindering

now we've redirect service whihc handles only when edge doens't have this data so this serviceget data from redis and gives to user or redirect where if data not in redis it goes to db and et the data and redirect and also stores in redis for next response minimising latency

here we're usig db(sql) to map all the urls to their id for better fetchin gand saving space for large user data

also helps to perform acid transactions

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.

here the main component are

1. id generation service is crucial cause even a single hallucination in repetitive same id generation will lead to in loop where it can affect the service badly cause this is core of the system. so this must be designed /algorithm/provider must be chosen considering for large scale system
2. database partioning and indexing so that easier and faster data retrival
   1. if we lok if we put 1 billion record in same db it becomes heavy executiun and for inndexing better is to particion db based on id or sharding we can do in our postgresql and mongodb

3 so we're using mongo, postgresql, redis so we can scale it horizontal to handle more traffics

BUT WE CANT scale it more casue it's not rscy to hancle routing request to many node and may lead to data inconsistency