Requirements

Functional Requirements:

Users can submit a long URL and receive a unique short URL.

Accessing a short URL redirects the user to the original URL.

URLs are permanent by default, with optional expiration/TTL.

Anonymous URL creation is supported.

Custom aliases are supported as an optional feature.

Analytics are out of scope for the initial version.

Non-Functional Requirements:

Scale: ~100M new URLs/month and ~4K redirects/sec average, ~12K/sec peak.

Read-heavy: The system should efficiently handle a 100:1+ read/write ratio.

Low latency: Redirects should be served with very low latency.

High availability: Redirects should remain available even if a region or server fails.

Global: The service should support users worldwide with multi-region reads.

Durability: URL mappings should not be lost.

Consistency: A short URL must resolve to the correct long URL; writes should avoid conflicting mappings across regions.

Capacity Estimation

We'll assume URL creation remains roughly flat at 100M/month for the initial design. At 1 KB per URL record, this is ~1.2 TB/year or ~6 TB over 5 years. Peak redirect traffic is ~12K requests/sec, resulting in roughly 12 MB/sec of outbound data assuming a 1 KB record. Storage is therefore manageable; read throughput, latency, and availability are the primary design concerns.

API Design

Create short URL

Response:

expires_at and custom_alias are optional.

2. Redirect

Example:

Response:

3. Optional delete

Since anonymous users don't have accounts, deletion creates an interesting authorization problem. I'd leave DELETE out of v1 unless Codemia asks for URL management.

High-Level Design

I'd aim for this:

But because the system is global, I'd extend that conceptually:

What each component does

Load balancer / global routing

• Sends users to a nearby healthy region.
• Provides horizontal scaling and failover.

URL service

• POST /v1/urls: generates a short code and stores the mapping.
• GET /{short_code}: looks up the mapping and returns a redirect.
• Stateless, so we can add more instances easily.

Cache

• Stores short_code → long_url.
• This is critical because reads vastly outnumber writes.
• Cache hit avoids a database query.
• Use TTL/invalidation to handle expiring URLs.

Database

• Source of truth for URL mappings.
• Something like:

The key flow to explain

Create URL:

Redirect:

Use a centralized/distributed Key Generation Service (KGS) that allocates a unique numeric ID for each URL. We then Base62-encode that ID to produce the short code. Because the KGS guarantees each ID is allocated only once, concurrent requests cannot generate the same short code.

Database Design

Yes. For the database section, I'd keep the first pass deliberately simple. The key insight is that the database is optimized around the redirect lookup:

short_code → long_url

You can put this into Codemia:

Database schema

URL mapping table

The primary key is short_code because every redirect starts with the short code.

Indexing

The primary key automatically gives us an efficient lookup:

So the redirect path is an O(log N) indexed lookup if it reaches the database.

We don't need additional indexes for the core redirect path.

If we later add URL management or expiration cleanup, we could add secondary indexes such as:

but those aren't necessary for the hot redirect path.

Sharding

At ~6 TB over five years, storage capacity isn't our main reason to shard.

However, because we're globally distributed and expect ~12K peak redirects/sec, we may eventually shard for throughput and availability.

A natural strategy is:

This distributes URL mappings relatively evenly across shards.

For example:

The application can determine the correct shard directly from the short code, so there's no scatter-gather query.

One important point

Because our cache absorbs most reads, the database doesn't actually need to handle the full 12K redirects/sec. The path is:

So I'd not introduce database sharding in v1 just because the number is 12K/sec. I'd design the schema so it can shard later, while initially relying on replication + caching.

Detailed Component Design

1. Concurrent URL creation — collision-free IDs

Use a Key Generation Service (KGS) that allocates unique IDs, potentially in pre-allocated ranges to different regions.

The KGS guarantees that two concurrent requests never receive the same underlying ID.

2. Prevent sequential ID enumeration

Don't expose the raw KGS counter.

Instead, transform/obfuscate the unique ID before Base62 encoding it.

For example:

The transformation must be:

• Deterministic — the same ID always produces the same short code.
• One-to-one — different IDs must produce different codes.
• Hard to reverse/guess — knowing one short code shouldn't reveal neighboring IDs.

A practical approach is a keyed permutation / format-preserving transformation over the ID space, followed by Base62 encoding.

This preserves the uniqueness property of KGS while preventing 1 → 2 → 3 → 4 from being exposed directly.

I'd explicitly say "Base62 is encoding, not encryption." Base62 alone does not solve enumeration.

3. Redirect → correct database shard

Use the short code to deterministically identify the shard:

This gives us:

One short-code lookup → exactly one database shard.

There is no scatter-gather across all shards.

If we use a consistent-hashing scheme, adding/removing shards causes less key movement than a simple modulo scheme.

4. Complete redirect path

Putting everything together:

And the create path