My Solution for Designing a Simple URL Shortening Service: A TinyURL Approach
by infinity6749
Requirements
Functional Requirements:
- Create a short URL for a given long URL.
- Return the long URL associated with a given short URL.
- Custom Alias option
Non-Functional Requirements:
- Low Latency
- Uniqueness of Short URLs
- High Availability, Eventual consistency
Capacity Estimation
100M Dau,
1Billion Urls Shortened Daily
Average 30 Days like active
API Design
POST /generate => Generate shortened URL
POST /validate => Validate if code doesnt already exists
POST /full => Get full url given shortcode
High-Level Design
CDN for high availability and low latency
API Gateway , redirects to services divided for read/write
Load Balancer on each service
Backend services separated as application is read heavy
we can have 2 services one for read one for write , read service can have multiple instaces
Redis for caching
DB Postgres/ SQL with indexing for faster reads
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.
Challenge #1 Unique Code generator
We can have multiple options to create unique id , but for expected 1B daily urls shortened we will go for base62 with 7 characters that will give us 3.5 trillion options , which is ideal
as these shortURL can have matching as we see in birthday paradox , so we have 2 options
- Use a counter
- check for existing unique id
As counter approach have tradeoff in microservice architecture of maintaining consistency of countyer across services , we are trading that off for an additional read
Challenge #2 Using queue for writes
We can rarely have user that will immediately open the link on generation , the basic idea of these kinds of app is to share the url , the sharing will take place the receiver will open the url , this can take about 5 min at average , with queues in place we can handle it
