Katkat
Back

Design short URL service with click counting

SnapchatSoftware Engineer · Technical Screen
HardSoftware EngineerTechnical ScreenSystem Design

Last updated

This question tests the ability to design a distributed URL shortening service, focusing on system architecture, database partitioning, and strategies for high-frequency write operations like click tracking.

System Design: URL Shortening Service with Real-time Click Analytics

Design a URL shortening service similar to bit.ly that supports high-traffic redirection and real-time click counting.

Functional Requirements

  1. Shorten: Users provide a long URL and receive a unique short URL.
  2. Redirect: When the short URL is accessed, the system redirects the user to the original long URL.
  3. Analytics: The system must provide the total count of clicks for any given short URL.

Non-Functional Requirements

  1. Scale: The system must handle 100 million new URLs per day and 1 billion daily redirects.
  2. Latency: Redirection must be extremely fast (< 50ms).
  3. Consistency: Click counts should be accurate, though eventual consistency is acceptable if it improves performance.
  4. Availability: The service must be highly available to prevent outages during traffic spikes.

Your Task

Provide a high-level system design that includes:

  • API Endpoints: Define the RESTful interfaces for shortening and analytics.
  • Data Model: Propose a schema that handles the mapping of short-to-long URLs and click metadata.
  • Architecture: Explain the choice of database (SQL vs. NoSQL), how you handle the generation of unique IDs, and how you manage click counting without bottlenecking the redirect path.
  • Trade-offs: Discuss the trade-offs regarding consistency (e.g., using counters vs. log-based aggregation) and how the system handles hot keys (very popular URLs).

Hints

Hint 1

Consider using an off-line or asynchronous processing model (like a message queue) for click logging to decouple the redirect path from the write-heavy analytics path.

Hint 2

Think about how to generate short, unique alphanumeric strings, and whether you prefer a centralized ID generator or distributed random generation.

Hint 3

For analytics, consider the trade-offs between using a standard database counter (RMW - Read-Modify-Write) versus a distributed cache like Redis to buffer increments.

Follow-up questions

  • How would you handle the 'hot key' problem if a single URL suddenly receives millions of hits per second?
  • How would you implement URL expiration or garbage collection for links that haven't been accessed in a year?
  • If we need to support geographical-based analytics (e.g., clicks by country), how would you modify the data storage and aggregation strategy?