Skip to main content
System Design Mafia
Back to patterns

URL Shortening Service like TinyURL

Scalable system design for creating short URLs, redirecting users, and collecting analytics.

//Component Breakdown

Key Components

Every box on the canvas, and the job it does. Click a card to locate it in the diagram; click the node itself for the full deep dive.

client×2
network×2
compute×5
database×1
cache×1
queue×1
//Deep Dive

Architecture Breakdown

Architecture Overview

This system designs a scalable, highly available URL shortening service, akin to TinyURL or Bitly. The architecture prioritizes low-latency redirects and high write throughput for creating new short links. It uses a read-heavy, async-first approach to handle massive traffic.

Core Data Flow

1. Short URL Creation (Write Path): - A client (browser or mobile app) sends a POST request with a long URL to the API Gateway. - The gateway handles authentication, rate limiting, and passes the request to the Load Balancer. - The load balancer routes the request to an available Application Server. - The application server requests a unique, pre-generated short code from the Key Generation Service (KGS). - The server then stores the mapping (shortCode -> originalUrl) in the Database. The database is a NoSQL store (like DynamoDB or Cassandra), chosen for its scalability and fast key-value lookups. - The newly created short URL is returned to the client.

2. URL Redirection (Read Path): - A client makes a GET request to a short URL (e.g., GET /abc123). - The request passes through the API Gateway and Load Balancer to an Application Server. - The application server first checks the Cache (Redis/Memcached) for the mapping. - If the mapping is not in the cache (a cache miss), the server queries the Database. - The retrieved original URL is returned as an HTTP 302 Redirect to the client.

3. Analytics & Cleanup (Async Paths): - Every redirection event is asynchronously logged to a Message Queue (Kafka). - An Analytics Service consumes these events to provide metrics like click counts, user locations, and referrers. - A separate Cleanup Service periodically removes expired links from the Database and Cache, and recycles their short codes back to the KGS.

Key Design Decisions & Trade-offs

  • Short Code Generation (Key Generation Service):
  • Database Choice (NoSQL):
  • Scaling the Database (Sharding):
  • Caching Strategy:
  • Purging & Data Lifecycle:
  • Analytics with 302 Redirect:
  • Security:

This architecture is designed to handle the high throughput and storage requirements of a global URL shortening service, balancing performance, scalability, and cost.

//A Word

From the Creator

Every great system starts as a sketch on a whiteboard. The ability to zoom out and see the whole picture (how services connect, where data flows, what breaks and why) is what separates engineers who build features from engineers who build systems. This diagram is more than boxes and arrows. It's a map of decisions, trade-offs, and intentional design.

Studying architectures isn't just about passing interviews. It's about training your intuition. The more systems you take apart, the better you get at sensing where a monolith will crack, where a queue belongs, or when a cache is hiding a deeper problem. You start seeing patterns instead of chaos.

So keep reading, keep tracing those edges, keep asking "why this way and not that way." The engineers who truly understand large systems are the ones who never stop being curious about how things fit together. That curiosity is the only ingredient that really matters.

Atharva Arbat@arbat_atharva

//Explore

More Patterns