Loading...
Mainly 2 api end points:
Headers: Include system generated cache tags for cache handling and idempotency
Body:
{
"url":
}
Response:
{
"shortened-url":
}
along with ETag for cache hits/miss
Body:
{
"shortUrl":
}
Response:
{
"longUrl":
}
along with e-tag
Components required:
Services implementation:
DB Layer:
This layer handles data persistence, ensuring that URL mappings remain intact even in the event of system failures. It also supports scalability by allowing the system to handle a growing number of URL mappings as usage increases.
The storage layer typically utilizes a database or a distributed data store to maintain URL mappings. When a user creates a short URL, the service generates a unique identifier and stores it alongside the long URL in the database. For retrieval, when a short URL is accessed, the service queries the storage layer to fetch the associated long URL.
Entry layer (API Gateway):
The entry layer processes requests for both URL shortening and redirection. When a user submits a long URL, the entry layer forwards this request to the write path service, which handles the creation of the short URL. Conversely, when a user requests a short URL, the entry layer routes this to the read path service for resolution back to the original long URL.
This layer ensures that requests are efficiently managed and distributed across backend services, providing features like rate limiting, authentication, and logging. It can also implement caching strategies to reduce latency for frequently accessed URLs.
DB layer:
Use a No- sql db, for key value storage e.g: Mongo DB
Easy to scale horizontally
why:
For collision avoidance:
For generator failure:
In case of network partition:
Caching:
API gateway:
Initial entry layer, routing traffic to services. Manages security and auth. Has rate limiting to prevent exploitation. Fallback mechanism for unavailable URLs.
Why:
Rate limiting:
Handling Hot ids:
One effective approach is to use caching layers, such as a Content Delivery Network (CDN) or an in-memory cache like Redis, to store frequently accessed short URLs. By caching these hot IDs, you can serve requests directly from the cache, significantly reducing the load on the underlying database and ensuring faster response times. This is particularly useful for URLs that experience sudden spikes in traffic, as the cache can absorb the increased demand without impacting the database's performance.
Another strategy is to implement read replicas for your database. By distributing read requests across multiple replicas, you can alleviate the load on the primary database instance. This allows the system to handle a higher volume of read requests for popular short URLs while maintaining write operations on the primary instance. It’s essential to ensure that the replicas are kept in sync with the primary database to provide accurate and up-to-date information.
Additionally, consider using sharding techniques based on URL patterns or user segments. By distributing hot IDs across multiple shards, you can balance the load more evenly. For instance, you could hash the short URL to determine which shard it belongs to, ensuring that requests for popular URLs are spread out rather than concentrated on a single shard.