ishavasya

13. Designing a URL Shortener System from Scratch

24 min read

The problem

We want to build a system that takes a long URL such as:

https://example.com/products/summer-sale?campaign=abc123&ref=homepage-banner

and turns it into something short such as:

https://sho.rt/aZ91Kx

When a user visits the short URL, the system should redirect them to the original long URL.

That sounds small, and at the simplest level it is small.

But once you think like a system designer rather than like someone writing a quick script, the problem becomes much richer.

A real URL shortener may need to handle:

  • very high read traffic
  • custom aliases
  • expiration
  • abuse and malicious links
  • analytics
  • rate limits
  • reliable low-latency redirects
  • duplicate handling
  • multi-region deployment
  • operational visibility

So this is a very good design exercise because the core idea is simple, but the surrounding engineering decisions reveal how real systems are built.

The right way to approach it is not to jump straight into tables or frameworks.

We first define what the system is supposed to do, then derive the architecture from that.

What the system fundamentally does

At its heart, a URL shortener performs two operations:

  1. shorten
    A client sends a long URL and receives a short code or short URL.

  2. redirect
    A user hits the short URL, and the system resolves the code to the original URL and returns a redirect response.

That is the irreducible core.

Everything else is built around those two actions.

This is useful because if you get lost in complexity later, you can come back to this center:

  • create mapping
  • resolve mapping

Start with product thinking, not technical thinking

Before architecture, ask what kind of product this is.

There are several possible product shapes:

  • a tiny internal tool for one team
  • a public internet shortener like Bitly or TinyURL
  • a branded enterprise link system
  • a marketing analytics link platform
  • a redirect service embedded in a larger application

These are not the same system.

They share a core mechanism, but they differ in:

  • scale
  • trust model
  • analytics needs
  • abuse risk
  • customization
  • uptime expectations

So a strong design starts by fixing the target.

For this note, we will design a modern production-grade shortener with these characteristics:

  • public-facing HTTP service
  • can support anonymous or authenticated link creation
  • supports high read traffic
  • supports optional analytics
  • supports custom aliases
  • supports expiration and disabling
  • must be resilient to abuse
  • should scale horizontally

This target is rich enough to teach the important ideas.

Functional requirements

The system should support at least:

  • create a short URL from a long URL
  • redirect from short URL to long URL
  • optionally create custom aliases
  • optionally set expiration time
  • optionally disable or delete links
  • optionally collect click analytics
  • optionally support authenticated users and ownership

These are the user-visible capabilities.

Now we derive technical needs from them.

Non-functional requirements

A URL shortener is usually much more read-heavy than write-heavy.

That single observation drives much of the architecture.

Important non-functional requirements:

  • very low latency redirects
  • high availability
  • horizontal scalability
  • read-heavy optimization
  • durability of mappings
  • protection against abuse
  • operational simplicity where possible

If the redirect path is slow, the service feels broken even if the rest is elegant.

So the system must treat redirection as a high-priority path.

The first conceptual model

At the most basic level, a shortener stores mappings like this:

  • short code → long URL

You can think of the core data model as:

ShortLink
  id
  shortCode
  longUrl
  createdAt
  expiresAt?
  status
  ownerUserId?
  customAlias?

You may later add analytics or metadata, but this is the essential record.

This is an important moment in system design:

we do not start with five databases and a queue.

We start with the minimal truth the system must preserve.

The core user flows

There are really two dominant flows.

Flow 1: Shorten a URL

sequenceDiagram
    actor Client
    participant API as Shortener API
    participant DB as Metadata Store
    participant ID as Code Generator

    Client->>API: POST /shorten(longUrl, options)
    API->>API: validate request
    API->>ID: generate short code
    API->>DB: store mapping
    DB-->>API: saved
    API-->>Client: short URL

Flow 2: Redirect

sequenceDiagram
    actor User
    participant Edge as Redirect Service
    participant Cache as Cache
    participant DB as Metadata Store

    User->>Edge: GET /aZ91Kx
    Edge->>Cache: lookup code
    alt cache hit
        Cache-->>Edge: long URL
    else cache miss
        Edge->>DB: lookup code
        DB-->>Edge: long URL
        Edge->>Cache: populate cache
    end
    Edge-->>User: 301/302 redirect

This already tells you something important:

the write path and the read path are different, and the read path deserves stronger optimization.

Why this system is mostly about reads

In most real shorteners:

  • a link may be created once
  • but clicked thousands or millions of times

That means:

  • writes are important for correctness
  • reads dominate cost and performance pressure

This is a classic read-heavy system.

Read-heavy systems often benefit from:

  • caching
  • replication
  • denormalized lookup paths
  • keeping the hot path extremely small

So from very early in the design, you should already expect:

  • one authoritative store
  • one fast cache for redirect resolution

That is a natural shape here.

Redirect semantics: 301 or 302?

Even the redirect itself has design meaning.

Common choices:

  • 301 Moved Permanently
  • 302 Found
  • 307 Temporary Redirect

Why does this matter?

Because redirect status affects:

  • browser behavior
  • caching behavior
  • semantic meaning

If links can later be edited or disabled, a permanent cache-friendly redirect may not always be what you want.

A practical design often uses:

  • 302 or 307 when flexibility matters
  • 301 when permanence is intentional

This is a small detail, but it shows a deeper principle:

protocol semantics are part of system design, not just implementation trivia.

The first naive implementation

A naive design might be:

  • one web server
  • one relational database table
  • generate a random short code
  • redirect by looking up the code in the table

This can work for a small system.

In fact, it is often the right way to start.

A lot of bad architecture begins when people skip the simple version and overbuild before pressure exists.

So the first version is something like:

Client -> API server -> database

with a table such as:

short_links
  id
  short_code UNIQUE
  long_url
  created_at
  expires_at NULL
  status
  owner_user_id NULL

This is a good starting point because it solves the real problem before introducing distributed complexity.

The real design pressure appears in code generation

Once the basic system works, one of the first architectural questions appears:

How do we generate short codes?

This seems like a detail, but it is actually central.

A short code should ideally be:

  • unique
  • reasonably short
  • safe in URLs
  • fast to generate
  • hard enough to guess if that matters
  • scalable without constant collisions

There are several broad strategies.

Strategy 1: Random code generation

Generate a random string such as:

aZ91Kx

Benefits:

  • simple
  • does not reveal total sequence count
  • easy to distribute across many app instances

Problems:

  • collisions are possible
  • uniqueness must be checked
  • as the system grows, collision handling matters more

This can work well if:

  • the code space is large
  • collision checks are cheap
  • traffic is manageable

For example, base62 with 6 or 7 characters gives a large space, but production systems still need collision handling discipline.

Strategy 2: Sequential ID + encoding

Another common strategy:

  1. assign an internal numeric ID
  2. encode that ID in base62

Example:

  • internal ID: 1258391
  • short code: 5DnP

Benefits:

  • guaranteed uniqueness if IDs are unique
  • no collision retries
  • easy deterministic mapping

Problems:

  • predictable sequence
  • can reveal rough traffic volume
  • distributed ID generation becomes a separate concern at scale

This is often one of the cleanest practical designs.

If predictability is acceptable or mitigated, it is very attractive.

Strategy 3: Hash-based approaches

You can hash the long URL or some unique input and shorten from that.

Benefits:

  • can help with deduplication thinking
  • deterministic in some designs

Problems:

  • collisions still exist when truncated
  • long URLs should not map blindly if ownership or expiration differs
  • deduplication by raw URL is not always semantically correct

So hashing is usually not the full answer by itself.

It may play a supporting role, but it is not the cleanest primary key strategy for most production systems.

What strong systems usually prefer

A very strong practical design is usually one of:

  • random base62 code with uniqueness check
  • unique numeric ID encoded to base62

If I were designing for clarity and reliability from scratch, I would usually prefer:

stable unique ID generation plus base62 encoding

Why?

Because it makes uniqueness simple and keeps code generation cheap and deterministic.

Then, if business requirements demand stronger unpredictability, I might add:

  • obfuscation
  • salted encoding
  • non-sequential public code mapping

This is a good example of architectural maturity:

first solve identity cleanly, then solve exposure semantics.

Why base62 is a natural choice

Base62 typically uses:

  • 0-9
  • a-z
  • A-Z

This is popular because it is:

  • compact
  • URL-friendly
  • human-copyable enough

It gives more information density than decimal while staying readable and safe in URLs.

You could also use base64 variants, but plain base64 brings characters that are awkward in URLs unless you use URL-safe variants carefully.

So base62 is a very common and sensible choice.

Deduplication: should the same long URL always return the same short URL?

This is a product and architecture question, not a purely technical one.

At first glance, deduplication sounds attractive:

  • if two people shorten the same long URL, return the same short code

But in real systems, that may be wrong because:

  • different users may want separate analytics
  • different links may expire at different times
  • one link may be public and another private
  • one may use a custom alias

So many strong systems do not globally deduplicate by long URL alone.

Instead:

  • each shorten request creates its own link object
  • optional duplicate detection may be offered within a user or account scope

This is a subtle but important design insight:

the business meaning of “same URL” is usually not enough to define “same short link.”

Custom aliases

A good shortener often allows:

https://sho.rt/summer-sale

instead of only generated codes.

This introduces a second namespace:

  • system-generated codes
  • user-chosen aliases

Design concerns:

  • uniqueness
  • reserved words like admin, login, health
  • profanity or abuse filtering
  • alias length rules
  • case sensitivity rules

A clean implementation often treats custom aliases as just another form of short code, but with:

  • stricter validation
  • uniqueness checks
  • policy checks

This is a reminder that “one field in the table” can still imply meaningful product logic.

Expiration and status

Links are not always permanent.

Common lifecycle states may include:

  • active
  • expired
  • disabled
  • deleted logically

Expiration may be:

  • never expires
  • expires at a timestamp
  • one-time use in rare designs

This matters in the redirect path:

before redirecting, the system must check:

  • does this code exist?
  • is it active?
  • has it expired?

That means status and expiry logic are part of the hot path.

So they should be easy to evaluate quickly.

Abuse is a first-class requirement

A public URL shortener will be abused.

That is not a pessimistic guess.

It is a standard assumption.

Abuse may include:

  • phishing links
  • malware distribution
  • spam campaigns
  • obscene or impersonating aliases
  • traffic amplification attempts
  • bot-driven link creation

So a serious design needs at least some combination of:

  • rate limiting
  • CAPTCHA or friction for anonymous creation
  • safe browsing or threat intelligence checks
  • domain blacklists
  • abuse reporting
  • moderation and takedown workflows

This is not “extra polish.”

For a public shortener, this is part of the core system design.

Why analytics changes the architecture

If the system only redirects, the design is fairly simple.

But if you also want analytics such as:

  • click count
  • timestamp of clicks
  • geographic distribution
  • user-agent information
  • referrers

then the redirect path becomes more interesting.

The risk is obvious:

if every redirect performs a heavy synchronous analytics write, you slow down the hottest path in the system.

That is usually the wrong design.

So analytics should typically be decoupled from the immediate redirect response.

A better analytics flow

A stronger design is:

  1. resolve link
  2. return redirect as fast as possible
  3. emit click event asynchronously

That may look like:

flowchart LR
    A[User requests short link] --> B[Redirect service]
    B --> C[Lookup target URL]
    C --> D[Return redirect immediately]
    B --> E[Emit click event]
    E --> F[Analytics queue/stream]
    F --> G[Analytics processor]
    G --> H[Analytics store]

This is a classic architectural move:

take a non-critical side effect and move it off the latency-sensitive path.

That is one of the signatures of mature system design.

The database choice

What kind of storage should back the link mapping?

The core requirement is:

  • fast key-based lookup by short code
  • durable writes
  • uniqueness guarantees

This makes both relational and key-value styles plausible.

Relational database

Benefits:

  • strong consistency
  • unique constraints
  • good support for metadata and querying
  • easy lifecycle and admin operations

This is often a very strong default.

NoSQL key-value style

Benefits:

  • very fast lookup patterns
  • horizontal scale in some environments
  • natural fit for simple code-to-URL retrieval

But:

  • metadata querying
  • admin reporting
  • consistency guarantees

may become more nuanced depending on the store.

For a production system designed clearly from scratch, a strong first choice is often:

  • relational primary store for metadata and correctness
  • cache in front for hot lookups

That gives a clean operational model.

Why cache belongs naturally here

The redirect lookup is a read-mostly, key-based access pattern.

That is exactly where a cache shines.

If many users repeatedly access the same short code:

  • the database should not be hit every time

A cache such as Redis fits naturally in front of the metadata store.

Typical pattern:

  • lookup short code in cache
  • on miss, fetch from DB
  • populate cache

The cache entry might include:

  • long URL
  • status
  • expiry

This keeps the redirect path very fast.

Cache invalidation concerns

Once you add a cache, you inherit cache invalidation problems.

If a link is:

  • disabled
  • expired
  • edited

then cached data may become stale.

You must choose how to handle that.

Common strategies:

  • short TTLs
  • explicit invalidation on update
  • cache-aside pattern with version-aware updates

Because most links probably do not change often, this problem is manageable, but it must still be designed intentionally.

This is one of the first real examples of a universal system design truth:

performance layers always introduce consistency considerations.

The write path in more detail

Let us now think more carefully about POST /shorten.

The request may include:

  • long URL
  • optional custom alias
  • optional expiration
  • optional metadata such as title or tags

The service must:

  • validate the URL format
  • validate allowed schemes like http or https
  • check blacklists or abuse rules
  • reserve or generate the code
  • write the record durably
  • possibly prime the cache

This is not a hard flow, but it is one where correctness matters more than raw speed.

The user will tolerate slightly slower creation far more than they will tolerate slow redirects.

This prioritization should affect where engineering effort goes.

URL validation is more subtle than it looks

If you accept arbitrary strings as long URLs, you invite trouble.

Validation concerns include:

  • valid URI structure
  • allowed schemes
  • normalization rules
  • whether to allow IP-based URLs
  • whether to allow local or internal network targets

For a public shortener, you often want to be careful about things like:

  • javascript: URLs
  • internal network addresses
  • localhost targets
  • file-like or dangerous pseudo-protocols

This is partly security and partly abuse prevention.

A strong design treats target validation as a first-class responsibility.

Read path optimization should be brutally simple

The redirect path should ideally do as little as possible:

  1. parse short code
  2. lookup mapping
  3. verify active/allowed
  4. return redirect
  5. emit analytics asynchronously if needed

That is it.

This is worth emphasizing because immature systems often put too much logic in hot paths.

The redirect service should not:

  • join many tables
  • compute heavy derived data
  • wait on analytics writes
  • call multiple downstream services if avoidable

The hottest path should be small, predictable, and operationally boring.

That is a hallmark of excellent systems.

The first scalable architecture

Once traffic grows, a natural architecture emerges:

flowchart TD
    U[Users / Clients] --> LB[Load Balancer / Edge]
    LB --> R[Redirect API Instances]
    R --> C[Cache]
    R --> DB[(Primary Metadata DB)]
    R --> Q[Event Queue / Stream]
    Q --> A[Analytics Workers]
    A --> ADS[(Analytics Store)]

The creation API may be served by the same service or a separate API tier, but the key architectural ideas are now visible:

  • stateless app instances
  • shared authoritative metadata store
  • fast cache
  • asynchronous analytics pipeline

This is already a strong modern system.

And notice: it is not needlessly exotic.

It is clear because each component exists for a concrete reason.

Why stateless application instances help

If redirect and creation services are stateless, then:

  • you can scale them horizontally
  • one instance can fail without losing durable state
  • load balancing becomes straightforward

State that must survive belongs in:

  • the database
  • the cache if rebuildable
  • the queue/stream for analytics events

Keeping application instances stateless is a general architectural advantage in web systems, and it fits especially well here.

High availability and replication

If the shortener matters to real users, downtime hurts immediately.

High availability usually means:

  • multiple application instances
  • database replication or failover strategy
  • replicated or highly available cache setup
  • health checks
  • rolling deployment support

Because redirects are read-heavy, read replicas may help some designs, but often the cache absorbs much of the pressure first.

You should not jump to replicas before understanding whether the cache already solves most lookup load.

Good architecture prefers measured pressure-driven complexity.

Multi-region thinking

If the service is global, latency to one central region may become noticeable.

Possible strategies:

  • single-region origin with CDN or edge caching
  • multi-region read caches
  • replicated metadata globally
  • geo-routing

But multi-region introduces complexity:

  • replication delays
  • invalidation propagation
  • failover coordination

For a shortener, a very practical progression is often:

  1. one primary region
  2. CDN or edge acceleration for redirect traffic
  3. distributed caches
  4. only later, deeper multi-region writes if truly needed

This progression is sane because the system is lookup-heavy and can benefit enormously from edge-friendly design.

CDN and edge value

Short-link redirects often benefit from edge distribution because:

  • request path is small
  • response payload is tiny
  • latency matters

Even if the final redirect target is elsewhere, fast resolution at the edge improves perceived speed.

A CDN or edge layer may help with:

  • TLS termination
  • DDoS resistance
  • caching some redirects
  • geographic request distribution

This is especially attractive for popular public links.

How to think about the primary key

The human-visible short code may not need to be the only identity in the system.

A strong design usually distinguishes:

  • internal durable record ID
  • public short code

Why?

Because internal IDs help with:

  • relational consistency
  • analytics joins
  • ownership and admin operations

while public codes serve:

  • redirect lookup
  • user-facing identity

Separating internal identity from public address is often a sign of mature schema design.

A clean data model

A practical production model might be:

short_links
  id (internal primary key)
  short_code (unique public code)
  long_url
  created_at
  created_by_user_id NULL
  expires_at NULL
  status
  is_custom_alias
  title NULL
  metadata JSON NULL
 
click_events
  id
  short_link_id
  clicked_at
  ip_hash or privacy-safe client fingerprint data
  user_agent
  referrer
  country_code

Depending on scale, click events may belong in a separate analytics store rather than the main transactional database.

That separation usually becomes attractive quickly, because click volume can dwarf link metadata volume.

Privacy and analytics

If you collect analytics, you are collecting potentially sensitive behavioral data.

So strong design requires deliberate decisions about:

  • whether to store raw IPs
  • how long to retain click data
  • whether to hash or anonymize identifiers
  • whether to support opt-out or compliance obligations

This is not only legal or policy overhead.

It is part of the data design.

The best architects do not bolt privacy on later as an afterthought.

They choose data shapes with privacy in mind from the beginning.

Custom domains

Real shorteners often support:

  • sho.rt/abc123
  • brand.co/sale

This means the system may need to support multiple domains pointing to the same service.

That affects:

  • routing
  • certificate management
  • tenant or account ownership
  • namespace uniqueness

A custom domain feature turns the system from “one global namespace” into “code + domain aware routing.”

That is a meaningful extension, but still naturally fits the same core mapping model.

You may then model uniqueness as:

  • unique per domain

rather than:

  • globally unique code only

That is a great example of how product features reshape identity rules.

Security in the redirect path

A redirect seems harmless, but it can be abused.

Security concerns include:

  • open redirect misuse patterns
  • malicious destinations
  • admin abuse
  • enumeration of short codes
  • scraping analytics

Potential controls:

  • secure admin tooling
  • domain reputation checks
  • reserved namespace handling
  • rate limiting on creation
  • bot detection
  • abuse reporting and takedown

If public trust matters, the system must protect not only its uptime, but also the quality and safety of links it hosts.

Enumeration and guessability

If codes are short and sequential, attackers may enumerate them.

That can expose:

  • active public links
  • metadata leakage
  • analytics endpoints if not protected

Whether this matters depends on the product.

For a public shortener:

  • plain sequential discoverability may be undesirable

Possible mitigations:

  • longer code lengths
  • randomization
  • non-sequential external encoding
  • access control for private links

This is an example of a design question that starts in ID generation but ends in product trust and privacy.

Should redirects be cached by clients and intermediaries?

This depends on link mutability.

If links are immutable and permanent:

  • strong caching can reduce load greatly

If links may be disabled, edited, or expire:

  • aggressive client-side permanence may be dangerous

This is why semantics like 301 vs 302 matter operationally, not just conceptually.

Good system design always ties protocol decisions back to product behavior.

Operational observability

A production-grade shortener must be observable.

You should know:

  • redirect latency
  • cache hit rate
  • DB lookup latency
  • creation success/failure rates
  • top error classes
  • queue lag for analytics
  • abuse spikes
  • domain-level traffic patterns

Important observability tools include:

  • logs
  • metrics
  • traces
  • dashboards
  • alerts

The system is only well-designed if operators can understand whether it is healthy and where it is hurting.

This is one more sign of mature architecture:

operability is part of the design, not just a deployment concern.

Failure modes

A strong architect thinks in failures, not just happy paths.

Possible failures:

  • database unavailable
  • cache unavailable
  • analytics queue unavailable
  • code collision on creation
  • malformed or malicious input
  • link expired
  • abuse system false positives

What should happen?

For the redirect path:

  • if analytics fails, redirect should usually still succeed

For link creation:

  • if durable write fails, do not pretend success

For cache failures:

  • fall back to DB if possible

This is an important general design lesson:

decide which failures are fatal to the user-visible operation and which should degrade gracefully.

Backpressure and rate limits

Public systems need request controls.

Creation endpoints may need:

  • rate limiting by IP
  • rate limiting by account
  • quota enforcement
  • bot protection

Redirect endpoints may need:

  • DDoS protection
  • edge rate limiting for abusive patterns

Why?

Because a shortener can become both:

  • a spam platform
  • a traffic amplification target

Throughput is not enough.

Control matters too.

A note on consistency

This is not the hardest consistency problem in distributed systems, but consistency still matters.

Examples:

  • newly created link should resolve quickly
  • disabled link should stop resolving promptly
  • custom alias uniqueness must be preserved

A sensible design usually prefers:

  • strong consistency for creation and alias uniqueness
  • eventual consistency for analytics aggregation

This is a good architectural split:

  • user-facing correctness where identity and redirects matter
  • softer consistency where behavioral reporting is acceptable later

That is exactly how seasoned systems are often designed.

How I would design the creation API

A clean API might expose something like:

POST /links

Request:

{
  "longUrl": "https://example.com/products/summer-sale?campaign=abc123",
  "customAlias": "summer-sale",
  "expiresAt": "2026-12-31T23:59:59Z"
}

Response:

{
  "id": "lnk_12345",
  "shortCode": "summer-sale",
  "shortUrl": "https://sho.rt/summer-sale",
  "longUrl": "https://example.com/products/summer-sale?campaign=abc123",
  "createdAt": "2026-05-12T12:00:00Z",
  "expiresAt": "2026-12-31T23:59:59Z",
  "status": "active"
}

The important thing here is not the exact route name.

It is that the API models the link as a real resource with clear lifecycle fields.

How I would design the redirect service

The redirect path should be separate in your mind from the management API.

The management API is about:

  • create
  • inspect
  • disable
  • analytics

The redirect service is about:

  • resolve code fast
  • redirect correctly

This separation can exist:

  • logically in code
  • or physically in separate deployable services later

Even if you start in one application, keeping those concerns separate internally is excellent design hygiene.

C#-oriented implementation thinking

If I were sketching this in C#, I would think in terms of clear boundaries such as:

  • LinkCreationService
  • ShortCodeGenerator
  • LinkRepository
  • RedirectResolver
  • AnalyticsEventPublisher
  • AbuseCheckService

And the controller or endpoint layer would stay thin.

The key design principle would be:

  • domain/application logic should not be trapped inside the web framework

That keeps the system testable and portable.

But the language is not the architecture.

These same responsibilities exist in any serious implementation.

The progression from simple to excellent

This system improves in stages.

Stage 1

Single service, single database, simple random or encoded code generation.

Stage 2

Add validation, alias support, expiration, status.

Stage 3

Add cache for redirect hot path.

Stage 4

Move analytics off the redirect path into asynchronous events.

Stage 5

Add abuse controls, rate limits, observability, high availability.

Stage 6

Add custom domains, better global performance, stronger policy controls, privacy-aware analytics.

This staged progression matters because good architecture often grows by clean extension, not by giant speculative design at day one.

The final architecture I would choose

If asked to design a strong production-grade URL shortener from scratch, I would choose this overall shape:

flowchart TD
    Client[Clients / Browsers / Apps] --> Edge[CDN / Edge / Load Balancer]

    Edge --> Redirect[Redirect Service]
    Edge --> API[Management API]

    Redirect --> Cache[(Redis / Cache)]
    Redirect --> MetaDB[(Primary Metadata Store)]
    Redirect --> Events[Event Stream / Queue]

    API --> MetaDB
    API --> Cache
    API --> Abuse[Abuse / Validation Layer]

    Events --> AnalyticsWorkers[Analytics Workers]
    AnalyticsWorkers --> AnalyticsDB[(Analytics Store / Warehouse)]

    Admin[Admin / Ops Tools] --> API

This design is strong because every component has a clear reason:

  • Edge reduces latency and absorbs internet-facing concerns.
  • Redirect Service keeps the hot path minimal.
  • Management API handles slower control-plane actions like creation and lifecycle changes.
  • Metadata Store is the durable source of truth for links.
  • Cache accelerates redirect resolution.
  • Event Stream decouples analytics from redirect latency.
  • Analytics Store handles high-volume click data separately from transactional metadata.
  • Abuse Layer protects the platform from becoming dangerous.

Notice what is good about this architecture:

  • it is not overcomplicated
  • it is easy to explain
  • it scales in the directions the workload actually needs
  • it separates correctness-critical state from high-volume analytics
  • it respects the difference between hot path and side effects

That is usually what excellent architecture feels like.

It is not flashy.

It is clear because the designer understands the forces acting on the system.

What you should come away with

If you understand this system properly, you should now be able to reason from scratch about:

  • the difference between the write path and the read path
  • why short code generation is a real design choice
  • why the redirect path must stay simple
  • why cache is natural in this system
  • why analytics should be asynchronous
  • why abuse handling is core, not optional
  • why consistency needs differ between redirects and analytics
  • why product requirements like custom domains and aliases reshape identity rules
  • how a simple MVP grows into a production-grade platform

That is the real point of this note.

The goal is not only to know “what a URL shortener is.”

The goal is to think like a system designer who can derive a strong architecture from first principles.

Bottom line

A URL shortener looks trivial until you define it properly. At its core it is a durable mapping system from short code to long URL, with one write path for creating mappings and one much hotter read path for resolving them. Once you design honestly for scale, you quickly discover the important forces: code generation, fast key lookup, caching, redirect semantics, link lifecycle, abuse prevention, asynchronous analytics, operability, and global performance. The best design is not the most exotic one. It is the one that keeps the redirect path minimal, keeps durable truth simple, moves non-critical side effects off the hot path, and grows cleanly as product and scale requirements increase.

Graph View