Requirements

Shorten a Long URL
- Users can submit a long URL.
- The system generates a unique, short alias.
- Example:

https://example.com/articles/system-design/url-shortener
↓
https://sho.rt/aB3xYz

Redirect to the Original URL
- When a user visits the short URL, the system redirects them to the original URL using an HTTP 301 or 302 redirect.
Ensure Uniqueness
- Every short code must uniquely map to a single long URL.
- No collisions should occur, or they must be detected and resolved.
Persist URL Mappings
- Store the mapping between the short code and the original URL so it survives server restarts and failures.
Handle High Read Traffic
- The service should efficiently serve a large number of redirect requests, as reads will significantly outnumber writes.

Non-Functional Requirements:

Target: 99.99% availability (four nines), allowing approximately 52.6 minutes of downtime per year.
Why: Every shortened URL depends on the service. If it's unavailable, users cannot access the destination links, impacting websites, emails, marketing campaigns, and applications.

Target: P95 < 50 ms and P99 < 100 ms for redirect requests within the same region.
Why: Redirects are on the critical path of every user click, so they should feel nearly instantaneous.

The system should scale horizontally to support:
- Billions of stored URL mappings.
- Millions of redirect requests per day (or higher, depending on traffic assumptions).
- A read-heavy workload, where redirects significantly outnumber URL creation requests.

Once a short URL is created, it should not be lost, even in the event of hardware failures or server crashes.
URL mappings should be stored in durable, replicated storage.

Every valid short URL should consistently redirect to the correct destination.
The system should gracefully handle transient failures through retries, failover, and redundancy.

Strong consistency for URL creation to ensure each short code maps uniquely to a single destination.
Eventual consistency is acceptable for non-critical data such as analytics and click counts, since slight delays do not affect the redirect functionality.

The service should continue operating despite failures of individual application servers, cache nodes, or database replicas.
Avoid single points of failure through redundancy and automatic failover.

Validate submitted URLs to reduce abuse.
Enforce HTTPS for all client communication.
Apply authentication and authorization where required (e.g., for user accounts and management APIs).
Use rate limiting to prevent abuse and denial-of-service attacks.

Design loosely coupled, modular components so new features (custom aliases, QR codes, analytics, branded domains) can be added without major architectural changes.
Support monitoring, logging, and observability for easier operations.

Optimize infrastructure for a read-heavy workload using caching and horizontal scaling.
Keep frequently accessed URL mappings in memory while using durable storage for long-term persistence to balance performance and cost.