High-Level Design

When many users create shortened URLs simultaneously, the system must ensure that generated short codes remain unique. To avoid collisions, the system uses a centralized ID generation strategy based on an auto-incrementing counter stored in the database or a distributed ID generator. Each new request obtains a unique numeric ID which is then encoded using Base62 to produce the short URL code.

Example flow:

Client → API Server → ID Generator → Base62 Encoder → Database

Because the generated IDs are guaranteed to be unique, the encoded short URLs will also be unique. This approach eliminates the need for repeated database checks that would otherwise be required when using random string generation.

To handle very high concurrency, the ID generator can allocate ID ranges to API servers so that each server can generate IDs independently without constantly querying the database.

Handling Generator Outage and Split-Brain Scenarios

The system must remain reliable even if the ID generator fails or multiple generators accidentally produce overlapping IDs (split-brain). To prevent this, the generator service runs in a replicated configuration with a leader election mechanism.

If the primary generator fails:

Replica generator becomes the leader

To avoid split-brain situations, generators coordinate using a distributed consensus system such as a leader election protocol. Each generator instance is responsible for a specific range of IDs, ensuring that no two instances generate the same IDs.

Additionally, the database enforces a unique constraint on the short_code column to guarantee that duplicate short codes cannot be inserted.

Cache Lookup and Cache Miss Handling

A caching layer is introduced to reduce database load and improve redirect latency. The system uses Redis as an in-memory cache.

Redirect request flow:

Client → Load Balancer → API Server → Cache

If the short URL exists in cache:

Cache Hit → Redirect immediately

If the short URL is not in cache:

Cache Miss → Query Database → Update Cache → Redirect

This approach ensures that frequently accessed URLs are served quickly while still maintaining correctness when data is not present in cache.

Cache TTL and Expiration Strategy

Cache entries include a time-to-live (TTL) value to prevent stale data from remaining in cache indefinitely.

Example:

short_code → long_url (TTL = 24 hours)

When the TTL expires, the next request results in a cache miss and the data is fetched from the database again. This ensures that cache entries remain fresh while keeping memory usage manageable.

To prevent a large number of cache entries expiring at the same time (cache stampede), the TTL values can include small random variations.

Cache Invalidation Strategy

When a URL mapping is updated or deleted, the corresponding cache entry must be invalidated to ensure consistency.

The system uses a cache invalidation mechanism where the API server deletes the relevant key from Redis after updating the database.

Flow:

Update request → Database updated → Cache key deleted

Alternatively, a publish-subscribe mechanism can be used where all API servers subscribe to cache invalidation events and remove outdated entries from their local caches.

Horizontal Scalability

The system is designed to scale horizontally so that it can handle increasing traffic.

Key design principles:

Stateless API Servers

API servers do not store session data locally, allowing new servers to be added easily behind the load balancer.

Client → Load Balancer → Multiple API Servers

New API instances can be added dynamically as traffic increases.

Distributed Database

The URL database can be partitioned across multiple database nodes using sharding.

Example:

Shard 1 → URLs starting with A–M
Shard 2 → URLs starting with N–Z

This allows the system to store billions of URLs while distributing the load across multiple machines.

Read Replicas

To improve read performance for redirect operations, additional read replicas can be introduced.

API Servers → Read Replicas → Primary Database

Write operations go to the primary database, while read operations can be distributed across replicas.

Reliability and Fault Tolerance

To ensure high availability, multiple instances of each component are deployed.

Multiple API Servers
Multiple Cache Nodes
Replicated Database

If one server fails, traffic is automatically routed to healthy instances by the load balancer. Database replication ensures that data remains available even if the primary node fails.

Submissions

Displaying Solutions with Scores Ranging from 1 to 10

Submissions

Displaying Solutions with Scores Ranging from 1 to 10