TinyURL System Design

1. The Framework: A Systematic Approach

Before diving in, let's quickly watch a clip that recaps the structured approach we'll be following. This is the exact methodology you should use to guide the conversation in a real interview.

2. Step 1: Clarifying Requirements

The first and most critical step is to scope the problem. Don't make assumptions. A senior candidate is expected to lead this conversation.

Let's watch how an experienced engineer clarifies the requirements for a URL shortener.

To solidify this, here is a text resource that provides a great checklist and example dialogue for requirement gathering.

For our design, let's consolidate the key requirements:

• Functional:
  • Generate a unique short URL from a long URL.
  • Redirect users from a short URL to the original long URL.
  • Support optional custom aliases.
  • Support link expiration.
  • (Optional) Track basic click analytics.
• Non-Functional:
  • Low Latency: Redirects must be very fast (e.g., < 100ms).
  • High Availability: The service, especially redirection, must be highly available. We'll choose Availability over strong Consistency.
  • Scalability: The system must handle a high volume of reads and a moderate volume of writes (a classic read-heavy system).
  • Uniqueness: Short codes must be unique.

3. Step 2: Back-of-the-Envelope Estimation

Now that we have a scale in mind, let's do some quick calculations. This step is vital to justify your design choices later (e.g., "Do we need to shard the database?" "How much cache do we need?").

Key Takeaways from Estimation:

• Read-Heavy: Read QPS (~11,500) is vastly higher than write QPS (~115). This immediately tells us to optimize the read path aggressively.
• Manageable Storage: The total storage (~5.5 TB over 5 years) is significant but can be handled by modern database systems, possibly even on a single powerful instance initially, but sharding is a necessary consideration for scaling.
• Short Code Length: A 7-character code using Base62 provides trillions of possibilities, giving us plenty of runway.

4. Step 3: API Design

With requirements defined, we can design the contract for our service. A clean, RESTful API is expected.

A crucial point in the redirection API is the choice of HTTP status code:

• 302 Found (Temporary Redirect): The browser will always check with your service for the destination URL. This is great for collecting analytics and allowing the destination to be updated, but it puts more load on your service.
• 301 Moved Permanently: The browser will cache the redirect permanently. This is extremely fast for the user and reduces your server load, but you lose the ability to track clicks or change the destination.

For a service like Bitly that relies on analytics, 302 is the standard choice.

5. Step 4: High-Level Design

Now we can start drawing the architecture. We'll begin with a simple setup and evolve it based on our requirements.

Based on our estimations, we know this is a read-heavy system. A common and effective pattern is to separate the read and write logic into different services. This allows them to be scaled independently.

6. Step 5: Deep Dive

This is where you demonstrate your depth as a senior engineer. We need to tackle the hardest parts of the design.

A. Unique URL Generation

This is the heart of the problem. How do we generate a unique, short, non-predictable code at scale? Let's explore the main strategies and their trade-offs.

The video introduces a great set of options. For a truly large-scale, distributed system, we need a solution that avoids the single-point-of-failure of a global counter while still guaranteeing uniqueness. This leads us to the industry-standard approach.

Recommendation for an Interview:
You should be able to discuss all three approaches. Start with the counter as the simplest, explain its flaws. Discuss hashing and its collision issues. Finally, present the distributed ID generator (Snowflake) as the most robust, scalable solution, demonstrating your understanding of distributed systems principles.

B. Scaling the System

With our components defined, how do we make them handle millions of users?

The LINK video we've been watching provides a great walkthrough of scaling each part of the system.

To tie everything together, here is a diagram of a more advanced, fully scaled-out architecture.

C. Database Choice: SQL vs. NoSQL

Your choice of database must be well-justified.

• The case for NoSQL (e.g., DynamoDB, Cassandra):
  • The core operation is a key-value lookup (short_code -> long_url), which NoSQL databases excel at.
  • They are designed for massive horizontal scalability and high availability, aligning with our non-functional requirements.
• The case for SQL (e.g., PostgreSQL, MySQL):
  • The data has a predictable, fixed schema.
  • ACID properties can be beneficial, especially for ensuring the uniqueness of custom aliases.
  • With proper indexing and replicas, a SQL database can handle significant read traffic. The storage requirement (a few TB) is well within the capabilities of modern SQL systems.

In an interview, a good answer is to recommend a NoSQL database like DynamoDB for the core URL mapping due to the simple access pattern and extreme scalability requirements, but acknowledge that a sharded SQL database is also a viable option. You could also suggest using a separate database (SQL or a specialized analytics DB like ClickHouse) for complex analytics queries.

Conclusion

Congratulations! You've just walked through a complete design for a URL shortening service, from requirements to a scalable, distributed architecture.

Key Takeaways:

• Follow the Framework: A structured approach (Requirements -> Estimation -> API -> HLD -> Deep Dive) is key to success.
• It's a Read-Heavy System: The 100:1 read-to-write ratio dictates every major decision. The read path must be heavily optimized with caching (CDN, Redis) and fast lookups.
• ID Generation is Crucial: The trade-offs between counter-based, hash-based, and distributed ID generators are the core technical deep dive. For a senior role, being able to design a Snowflake-like system is a major plus.
• Justify Your Choices: Every decision, especially the database choice, must be backed by reasoning tied to the requirements and estimations.

Next Lesson Preview:

A public service like a URL shortener is a prime target for abuse. To protect our system from being overwhelmed, we need to implement rate limiting. In our next lesson, we will compare rate limiting algorithms (token bucket, leaky bucket, sliding window) and their trade-offs, a critical component you would add to the API Gateway or application services in this design.