URL Shortener · Approach

01 · Develop the design

Plan the design

Use a stateless API, durable link mappings, cache-aside redirects, and asynchronous click processing. The diagram shows logical dependencies; production services may have multiple instances behind a load balancer.

Stage 1

Separate the two hot paths

Creation needs a durable write; redirect needs a fast lookup by code. Start by specifying POST /links and GET /:code, including unknown and expired links.

Stage 2

Make uniqueness a storage guarantee

Generate a random Base62 code, then insert it under a unique constraint. Retry a collision a bounded number of times. An existence check before insertion is not safe under concurrency.

Stage 3

Keep optional work off redirects

Read with cache-aside and bound the TTL by link expiry. Send analytics to a bounded queue consumed by a worker. Decide whether analytics loss is acceptable when the queue is unavailable.

02 · Work through the method

Step-by-step approach

Validate an absolute HTTP(S) destination and expiry. Generate an 8-character code using a secure random source. Insert the mapping with a unique code constraint; retry conflicts up to five times, then return a retryable error.
For redirects, look up the code in cache, then in the database on a miss. Return 404 if absent and 410 if expiresAt is in the past. Preserve expired records or tombstones for the documented retention period if 410 must remain distinguishable from 404.
Cache active records for min(defaultTTL, expiresAt − now). Recheck expiry even on cache hits. Return a 302 redirect so the service can continue checking expiry and collecting events on subsequent visits.
Enqueue a click event without waiting for analytics processing. Use bounded queue admission and a short timeout; if the analytics queue fails, still redirect and record a dropped-event metric under the stated best-effort analytics policy.
At 10,000 reads/s and an assumed 95% hit ratio, the database sees about 500 reads/s. At 100 creates/s and 500 bytes/record, new mappings consume about 4.32 GB/day before indexes, replicas and expiry. These are planning estimates, not measured limits.

03 · Justify the choices

Why this approach works

How do you allocate short codes?

Random Base62 with a unique constraint and collision retry

Random codes need a database uniqueness guarantee and bounded retries. Time alone and URL truncation can collide.

How should the cache behave?

Cache-aside with TTL bounded by link expiry

A hot mapping avoids database reads, but its cache TTL must not outlive the link. Enforce expiry on redirect too.

What happens if analytics is unavailable?

Redirect and use a bounded event queue with a documented loss policy

Keep analytics off the redirect critical path. Bound retries and queue growth, and state when events may be dropped.

04 · Plan the evidence

Validation strategy

Two concurrent inserts with the same generated code: one succeeds and the other retries.
A cache hit at the exact expiry boundary returns 410, never a redirect.
Unknown code returns 404; a retained expired mapping returns 410.
A saturated analytics queue or cache outage does not cause unbounded waits or memory growth.

Trade-offs to explain

Random codes avoid a central sequence allocator but require collision handling. Longer codes increase the available namespace.
Cache failures need bounded fallback, admission control and request coalescing to avoid overwhelming the database.
Best-effort click events can be lost. If loss is unacceptable, introduce durable event capture and explicitly revisit redirect availability and latency.
Add create-rate limits, abuse reporting and destination policy checks. Any future server-side URL fetching requires separate SSRF protections.