Requirements

Functional Requirements:

• Create a short URL for a given long URL.
• Return the long URL associated with a given short URL.
• need to be able to handle alot of incoming Get requests

Non-Functional Requirements:

• List the key neon-functional requirements (eg low latency, scalability, reliability, etc.)...
• need to be reliable for no one wants a break a link
• high availability is a must since broken shorts links destroy user trust
• service must scale horizationally to support increaseing traffic and data.
• need to be write light and read heavy system, since most people will click short links than generate them

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

Post/shorten - accepts long url and returns a new short url

Get/expand - given short url returns the associated long url

get / Shortcode handles incoming redirect requests

Post/customer user can provide a preffered short alias

get/ stats/ retrieve analytics

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.

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.

client - uer/mobile web calls to api s to shorten/aexpand/redirect

api gateway - routes traffic to backend services

shortening service - accepts long URLS and genrates a unique short code and writes to db

redirect service - reads from db, hanldes shortcodes

database - stores url mapping as above

cache like redis or memcache - for most common shortcodes to avoid db trips on hot urls

monitoring and metric and longing - track latenxies, errors, traffic and possible abuse.

optional analytics services... collects stats about each redirect event.