miji.beURL shortener architecture describes the overall internal design and technical components of a URL shortening service. It is also a popular system design interview topic and an excellent case study for learning scalable web service principles.
The basic architecture consists of three components. First, the URL shortening engine accepts a long URL, generates a unique short code, and stores the mapping in a database. Second, the redirect engine receives requests for short URLs, looks up the destination in the database, and returns a 301 or 302 redirect response. Third, the analytics engine collects click data and aggregates statistics.
Three main approaches exist for generating short codes. Counter-based generation converts a sequential ID to Base62. Hash-based generation takes the first N characters of an MD5 or SHA-256 hash of the URL. Random generation produces a random string and checks for collisions. The counter-based approach is the simplest and free of collisions, which makes it a common starting point. Its weakness is that the codes fall in sequence, so short URLs created by other people can be walked through mechanically. When the URLs are not meant to be public, the counter is usually transformed before it is exposed, or random generation with a collision check is used instead. Sharing one counter across several servers also raises the question of where the identifiers stay unique.
Caching is the key to scalability. A short URL is written once and then read every time someone opens it, so redirect handling is far more read-heavy than write-heavy, which makes Redis or Memcached highly effective. Keeping frequently opened short URLs in cache drastically reduces database queries and shortens the time needed to look up the destination. The wait a visitor actually perceives also includes the round trip between device and server, so caching alone does not determine it.
For the database layer, key-value stores such as DynamoDB or Redis are well suited to short URL lookups. The data model is straightforward: the short code is the key, and the original URL plus metadata is the value. Once reads and writes no longer fit on a single node, sharding the data by short code becomes an option. Splitting on the first character alone can pile rows onto one node depending on how codes are generated, so the partitioning scheme has to spread them evenly.