Dev.to #systemdesign·March 23, 2026

Designing a Scalable URL Shortener: A Beginner's Guide

This article outlines the fundamental system design framework by applying it to the classic URL shortener problem. It covers requirements gathering, scale estimation, API definition, data modeling, high-level architecture, and deep dives into critical components like short code generation and caching strategies. The guide emphasizes practical considerations for building a robust and performant distributed system.

Distributed Systems Databases & Storage Performance & Scaling

Read original on Dev.to #systemdesign

The System Design Framework Applied to a URL Shortener

The article introduces a structured 6-step framework for tackling system design challenges, which is then meticulously applied to designing a URL shortener. This framework includes clarifying functional and non-functional requirements, estimating scale to inform architectural decisions, defining clear APIs, designing data models, outlining high-level architecture, and deep-diving into critical components. This systematic approach helps break down complex problems into manageable parts.

Key Requirements and Scale Estimation

Functional Requirements: Create short URLs from long ones, redirect short URLs, support optional expiration and custom URLs.
Non-functional Requirements: High availability (99.9%), low latency (<100ms for redirects), and data durability.
Scale Estimation: Anticipating 100M new URLs daily and a 100:1 read/write ratio leads to ~1,160 writes/sec and ~116,000 reads/sec, with 18 TB storage over 5 years. This highlights the system's read-heavy nature and the need for caching.

API Design and Data Model

The API includes endpoints for creating, retrieving, and deleting short URLs. A key decision point for redirects is choosing between 301 (permanent) for caching benefits and 302 (temporary) for accurate analytics. The data model is simple, storing `short_code`, `long_url`, `created_at`, `expires_at`, `user_id`, and `click_count`, with `short_code` as the primary key.

sql

CREATE TABLE urls (
    short_code VARCHAR(7) PRIMARY KEY,
    long_url VARCHAR(2048) NOT NULL,
    created_at TIMESTAMP DEFAULT NOW(),
    expires_at TIMESTAMP,
    user_id BIGINT,
    click_count BIGINT DEFAULT 0
);

Short Code Generation Strategies

Hash + Truncate: Using MD5 hash and taking the first few characters. Prone to collisions, making it less suitable for high scale.
Base62 Encoding of a Counter: Incrementing a database counter and encoding it to Base62. Guarantees uniqueness and is suitable for distributed environments if the counter is managed atomically.
Pre-generated Keys (Key Generation Service - KGS): A dedicated service pre-generates unique short codes and stores them. Upon request, a code is moved from an 'available' pool to a 'used' pool, eliminating collision concerns and ensuring fast retrieval.

High-Level Architecture and Caching

The proposed architecture features a Load Balancer distributing requests to separate Write Service and Read Service components. The Write Service interacts with a Primary DB, while the Read Service leverages a Redis Cache (for ~99% hit rate due to read-heavy nature) and a Read Replica DB for cache misses. This split architecture optimizes for both write and read operations, ensuring high availability and low latency crucial for a URL shortener.

💡

Caching Strategy for Read-Heavy Systems

For systems with high read-to-write ratios, like a URL shortener, a robust caching layer is paramount. Placing a Redis cache in front of your database can drastically reduce database load and improve redirect latency, directly addressing non-functional requirements for performance.

URL ShortenerSystem Design InterviewScalabilityCachingDatabase DesignAPI DesignDistributed CounterKey Generation Service