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:

• Low Latency (200ms)
• Scalability 100k RpS
• Reliability total availability 99%

Questions:

• Can users see how their URLs performed? analytics?
• If yes, can two users with the same URL generate the same hash? my assumption is no.
• Do we need analytics for the whole system? or is this out of scope?

Capacity Estimation

We have read bias

Store Links indefinitely require an DB cluster

API Design

Post /v1/shorten

Body {"url": ""}

return 201 // no content

return 400 no valid url exists in the body

return 500 internal server error {"errorCode: int, message: ""}

GET

return 302 redirect

return 404 no short url found

return 500 internal server error {"errorCode: int, message: ""}

High-Level Design

• FE: just an input filled and a path
• API Server:
  • Resolve short URLs
  • Send shorten URL requests to URLProcessor service.
  • Send retrieve URL event to analytics engine.
• URLProcessor: perform the URL shortening logic, including hash collision resolution etc.
• Pubsub: for communicating SBE between FE and the URLProcessor Service.
• KV Store: for quickly caching the hot urls
• Message/event bus: to send a URL to URLProcessor
• Database: Store URL mapping wit metadata maybe
• Analytics Engine: Listens to the messages
• Analytics database: a timeseries database to store access patterns.

Notes on technology selection:

• NATS: supports the user cases of KV pubsub, and messaging queue
• With NATS durable storage I can claim that we don't even need another database. although I would use one for the analytic.

Database Design

Database can have a basic table called urls, it has very basic information based on the requirements above. since we are user agnostic then the URL should be maybe have url, hash, created at and last accessed (this will help with crashes later to auto reload last access urls/hot urls) the last access at field will be pushed as a bulk snapshot from the KV store.

Database can be shared using hash ranges to have stable shards and avoid rebalancing.

Detailed Component Design

FE:

• Typing a URL and hitting submit will do two things will send api request to shorten the URL and will subscribe to URLShortened Event with the URL as a key. in the pubsub
• Once it receives

URLProcessor:

• It receives a URL Creation Event
• Search for the URL in the database, if it exists just broadcast a URLShortened event to the pubsub ( this way we don't have to create anew shortedned URL to URLS we already have)
• if not then generate a hash and pull all hashes that have this has as a prefix. multiple exists then append a new suffix to the hash and then save the URL and broadcast URLShortened event