Requirements

Functional Requirements:

Core Requirements

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

1. 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.
2. Ensure Uniqueness
   • Every short code must uniquely map to a single long URL.
   • No collisions should occur, or they must be detected and resolved.
3. Persist URL Mappings
   • Store the mapping between the short code and the original URL so it survives server restarts and failures.
4. Handle High Read Traffic
   • The service should efficiently serve a large number of redirect requests, as reads will significantly outnumber writes.

Non-Functional Requirements:

1. High Availability

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

2. Low Latency

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

3. Scalability

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

4. Durability

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

5. Reliability

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

6. Consistency

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

7. Fault Tolerance

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

8. Security

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

9. Maintainability

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

10. Cost Efficiency

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

Capacity Estimation

Estimate the scale of the system. Consider daily active users, read/write ratio, storage requirements, bandwidth, and any relevant QPS calculations...

API Design

1. Create a Short URL

Endpoint

Request

• longUrl – Required.
• customAlias – Optional. If provided, the system checks whether it's available.
• expirationTime – Optional.

Success Response (201 Created)

Possible Errors

• 400 Bad Request – Invalid URL.
• 409 Conflict – Custom alias already exists.
• 429 Too Many Requests – Rate limit exceeded.

2. Redirect to the Original URL

Endpoint

Example:

Server Processing

1. Look up the short code in Redis.
2. On cache miss, query the database.
3. Record analytics asynchronously.
4. Return an HTTP redirect.

Response

Interview note: I'd use 302 Found by default because it allows the destination to change later if needed. If links are permanent and immutable, 301 Moved Permanently can improve browser and CDN caching.

3. Get Analytics

Endpoint

Response

Requires authentication since analytics belong to the link owner.

4. Delete or Disable a Short URL

Endpoint

Response

Only the owner (or an administrator) should be allowed to perform this operation.

5. Update Link Metadata (Optional)

Endpoint

Request

This endpoint can update mutable properties like expiration or enable/disable status. Whether to allow changing the destination URL depends on product requirements.

High-Level Design

+------------------+

| Client |

+--------+---------+

|

HTTPS Request

|

+--------v---------+

| DNS / CDN |

+--------+---------+

|

+--------v---------+

| Load Balancer |

+--------+---------+

|

+-------------+-------------+

| |

+-------v-------+ +-------v-------+

| API Servers | | Redirect |

| (URL Create) | | Servers |

+-------+-------+ +-------+-------+

| |

| |

+-------v-------+ +--------v--------+

| Redis Cache |<-------->| Read Cache |

+-------+-------+ +--------+--------+

| |

+-------------+-------------+

|

Cache Miss

|

+--------v---------+

| URL Database |

| (Primary + |

| Read Replicas) |

+--------+---------+

|

Async Event

|

+--------v---------+

| Message Queue |

+--------+---------+

|

+--------v---------+

| Analytics Service|

+--------+---------+

|

+--------v---------+

| Analytics DB |

+------------------+

Database Design

Define the data model. Identify the main entities, their attributes, and relationships. Consider the choice of database type (SQL vs NoSQL) and justify your decision based on access patterns...

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.