Design URL Shortener

URL shortener inspired by Bitly and TinyURL: collision-free base62 codes from pre-allocated id ranges, a key-value link store with conditional writes, cache-first and edge redirects, async click analytics and malicious-link scanning. A teaching design.

Functional requirements

  • Users can submit a long URL and receive a unique short code (e.g., prism.io/aB3xY) via the URL Shortening Service.
  • Visiting a short URL is resolved by the Redirection Service and returns an HTTP 301/302 redirect to the original long URL.
  • Users can optionally specify a custom alias; the system guarantees global uniqueness at creation time.
  • Short URLs expire after a configurable TTL (default: 1 year); a Cleanup Worker removes expired links, which then return 410 Gone.
  • Users can view click analytics (total clicks, referrers, geographic distribution) served from the analytics store.
  • Authenticated users can manage (update target, deactivate, delete) their own short URLs via the User Service.
  • The system blocks creation of short URLs pointing to known malicious or phishing domains, with CAPTCHA/bot-protection on suspicious flows.
  • Bulk short-URL creation is supported via a CSV upload API; an Export Worker produces downloadable CSV exports to object storage.
  • QR code generation is available for any short URL on demand.
  • Every redirect emits a click event to Kafka, consumed asynchronously by the Analytics Worker; notifications are delivered via a Notification Worker.

Non-functional requirements

  • Availability: 99.99% uptime across multiple availability zones and regions; the redirect path keeps serving cached mappings during partial DB or single-zone outages.
  • Latency: redirect response under 10 ms at p99 when served from the global Redis cache; under 50 ms on cache miss to a regional replica.
  • Scalability: support 10 billion active short URLs and 100,000 redirect requests per second on a stateless, horizontally scalable application layer.
  • Throughput: the messaging layer (Kafka) sustains high-throughput click/event fan-out without back-pressuring the redirect path.
  • Durability: all URL mappings persisted durably in Cassandra and replicated across at least 3 availability zones; backups and exports stored in object storage (S3/GCS).
  • Consistency: eventual consistency acceptable for analytics counters and replicas; strong consistency required for creation uniqueness.
  • Performance: 99% of redirect requests served from an in-memory Redis or CDN cache layer (cache-first).
  • Security: WAF/DDoS protection at the edge, per-IP and per-user rate limiting, input validation and blocklist checks, plus CAPTCHA/bot protection on creation.
  • Geo-distribution: Geo-DNS plus CDN edge nodes and multi-region read replicas serve redirects with minimal RTT worldwide.
  • Observability: real-time metrics, logs, and traces (Prometheus, ELK/OpenSearch, Jaeger) with Grafana dashboards and Alertmanager p99 alerting within 30 seconds.

How the design evolves

Stage 1: Hash-Truncated Codes and a Query per Redirect

See the collision and load problems of the obvious design.

What was missing: Nothing yet.

Why that's risky: Truncated hashes collide (two URLs get the same code) and must be detected and retried, and 50K redirects per second all hit one database.

What gets added: One server that makes codes by truncating a hash of the long URL and resolves every redirect with a database query.

Trade-offs: The same URL always gets the same code, at the price of collisions.

Stage 2: Unique Codes from ID Ranges and a Key-Value Store

Generate unique codes without collisions or coordination, and store links in a store built for lookups.

What was missing: Codes collided and every redirect queried a relational table.

Why that's risky: Every click still reads the link store, and clicks outnumber creations a hundred to one.

What gets added: An ID range allocator that hands each shorten server a block of a million ids, which it encodes in base62 into 7-character codes; a key-value link store with conditional writes so custom aliases can't clash; and a redirect service.

Trade-offs: Sequential codes are guessable; shuffling ids within each range (or adding a few random bits) avoids that.

Stage 3: Cache-First Redirects

Serve almost every click from memory.

What was missing: Every click read the link store.

Why that's risky: A link going viral sends its whole audience to our servers.

What gets added: A link cache in front of the store; since links never change, entries simply expire.

Trade-offs: Using 302 instead of 301 means browsers don't cache redirects themselves, keeping clicks countable at the cost of more requests.

Stage 4: Redirects at the Edge

Answer popular links from servers near the visitor.

What was missing: All redirects reached our servers.

Why that's risky: Clicks aren't counted for creators, and nothing checks for malicious destinations.

What gets added: An edge cache that answers redirects for popular codes for a few minutes, logging each click.

Trade-offs: A disabled link can keep redirecting at the edge until its entry expires, so edge TTLs are kept short.

Stage 5: Click Analytics and Safety Scanning

Count every click without slowing redirects, and stop malicious links.

What was missing: No analytics and no safety checks.

Why that's risky: Spammers can create links as fast as they like, and service health isn't watched.

What gets added: A click event stream (including edge-served clicks from edge logs) aggregated into an analytics store by time, country, referrer and device; and a safety scanner that checks new links against malware and phishing lists and disables bad ones.

Trade-offs: Analytics lag by a minute; new links are usable before scanning finishes and disabled if found bad.

Stage 6: Creation Limits and Monitoring

Stop mass link creation and watch the service.

What was missing: No creation limits and no monitoring.

Why that's risky: Remaining risk is regional: the link store should be replicated so redirects keep working if a region fails.

What gets added: Rate limits on link creation per account and IP, and monitoring of redirect latency, cache and edge hit rates, id range usage and disabled links.

Trade-offs: Strict creation limits slow legitimate bulk users; they can use an authenticated API with higher limits.

Frequently asked questions

How do you handle hot keys in a URL shortener?

Introduce key salting for popular URLs, cache hot entries aggressively, and shard by hashed key prefix.

Which consistency model is acceptable for reads?

Eventual consistency for replicas is acceptable with primary writes and fallback when lag increases.

How do you prevent thundering herd on cache miss?

Use request coalescing, soft TTLs, and background refresh to avoid stampedes.

Why keep the MVP architecture simple?

A single service and database reduce complexity and help validate core functionality quickly.

How does rate limiting protect the shortener?

Rate limiting prevents abusive spikes and preserves capacity for legitimate traffic.

Why move analytics to an async queue?

Async analytics decouple heavy writes from the request path and keep redirect latency low.

PRISM
System Design Interview
Round 1 of 4 · Architecture Design · 60:00 remaining
PRISM logo PRISM logo
Problems
AI Interview
Interview Challenges
Build & Stress Test NEW
System Architectures
Design & Fix NEW
Interactive Roadmap
System Design Guides Interview Prep Guide
Problems
Today's mission
Notifications
    Theme
    Pricing Community NEW Send feedback Report a problem NEW
    Sign in
    Theme
    Community NEW Send feedback Report a problem NEW
    All problems
    Phase
    Build & Stress Test
    Phase 01: Thinking in Systems
    Upcoming

    Components

    User
    CDN
    Load Balancer
    Server
    Cache
    Database
    Blob Storage
    Search Index
    Queue
    Worker
    Rate Limiter
    Service
    API Gateway
    Reverse Proxy
    WebSocket Server
    Third-party API

    Inspector

    Notes
    Use clear names so your design intent is easy to understand.
    Good
    Name by business meaning
    "Order API", "Restaurant Service"
    Avoid
    Generic names = zero signal
    "Server 1", "API", "Queue"
    A short description for each component makes feedback much better.
    100%
    Start by identifying:
    • Users & entry points
    • APIs & services
    • Databases & storage
    • Traffic flow & scale

    Round 1 of 4 Architecture Design

    Run a simulation to see results.

    Time Remaining
    60:00
    System Design Interview

    What are the core functional requirements?
    What are the key non-functional constraints?

    Questions

    Start Evaluation to unlock questions.

    EVALUATE MODE

    Test yourself like it's the real thing.

    A structured 4-module evaluation that mirrors how top companies assess system design candidates.

    Architecture Design
    Draw your system on the canvas. Define components, connections, and data flow.
    FR & NFR Requirements
    Answer functional and non-functional requirement questions about your design.
    MCQ Round
    Multiple choice questions testing your depth on the chosen system.
    Tradeoff Analysis
    Justify your design decisions and defend your architectural tradeoffs.
    AI Report Generated
    Choose a Problem
    No problem selected
    • 30 min
    • 45 min
    • 60 min
    Round 2 of 4
    MCQ Round
    Answer multiple-choice questions based on your design.

    Exit Interview?

    You're in the middle of an interview session. Leaving now will end your current attempt.

    Your progress will be saved.

    Open a saved design

    Select a design to load into the canvas.

    My Evaluations

    Your past evaluation sessions

    Here’s a simple request flow that follows the expected layer order.

    External User
    →
    Edge CDN → API Gateway → Load Balancer
    →
    Compute App Servers / Services
    →
    DataAccess Cache
    →
    Storage Database / Search Index
    →
    Async Queue → Worker

    Tip: keep arrows moving forward through layers (Edge → Compute → Storage). Avoid sending storage back to compute.

    Evaluation Instructions

    Read the rules carefully before starting. The test auto-submits on refresh.

    Before you start

    • Build your architecture on the canvas. The timer starts when you click Start Evaluation.
    • Don't forget to answer Functional Requirement and Non Functional Requirements.
    • When satisfied with your design, click Next to lock it and view the questions.
    • Please answer final step questions to complete the evaluation.

    Dos

    • Do read each question carefully before answering.
    • Do include required components to maximize component coverage.
    • Do save a copy of your design if you want to keep it before submission.

    Don'ts

    • Don't refresh or close the tab during an active evaluation — this will auto-submit your answers.
    • Don't switch app modes or open another tab while the evaluation is running.
    • Don't attempt to edit the design after clicking Next; the workspace will be locked.

    All the best!!

    Confirm

    Input

    Notice

    Evaluation Report
    Report a problem

    Evaluation Complete

    Generating Your Report

    Hang tight — our AI is evaluating your design…

    Did you know?

    Loading…

    Share feedback

    Tell us what worked well and what we can improve.

    Let's personalize this

    Answer a couple of quick questions so we can tailor your journey and missions.

    Your welcome gift: of Full PRISM Access

    Your Pro access starts as soon as you press Start my journey.

    SYSTEM BRIEF

    System Constraints

    What the system must do — every item is a user-facing behaviour your architecture must support.

      ↑ Engineering Constraints

      These are the failure modes you must design against — latency SLAs, durability targets, traffic ceilings.

        ⇆ Architecture Constraints

        Core Concepts to Master

        Your Journey
        PHASE – –
        0 / 0 0%
        0
        Mock Interview Checklist

        Pick a topic to start

        Explore concept overviews, real-system examples, key tradeoffs, and interview talking points for each roadmap section.

        Phase Mastered

        You've conquered this phase. These are the skills you now own:

          +500 XP

          Company Interview Paths

          Progress Summary