URL Shortener — Trade-offs & Decisions

How short codes are generated determines uniqueness handling, predictability, and coordination complexity. The right choice is workload-dependent — there is no single universally correct answer.

Selection criteria

Weigh: uniqueness guarantee strength required, predictability/enumerability requirements, coordination overhead the team is willing to operate, write throughput, whether generation must happen independently across multiple regions, resulting code length, collision/retry complexity, and general operational complexity.

The redirect status is a product decision with infrastructure consequences — not a fixed 'correct' choice, and not simply 'one caches, one doesn't.'

What actually drives the decision

Compare: repeat-request server load, client/intermediary caching behavior (governed by status plus explicit Cache-Control/Expires headers, not status alone), analytics visibility needs, whether destinations are mutable after creation, and how rollback/change behavior should work. A design that needs exact click analytics or supports editable destinations should lean toward a temporary-redirect posture; a design with genuinely immutable, high-traffic destinations can lean toward permanent-redirect caching to reduce load. Avoid stating either as universally correct — see Architecture Deep Dive → Redirect Semantics and HTTP Caching.

How much caching to add, and where, trades latency and database offload against consistency and operational complexity.

Consistency needs defensive correctness, not just a long TTL

A long TTL with explicit invalidation on mutation is a strong, efficient default — but it does not achieve perfect consistency. Failed/delayed invalidation, a local cache layer that wasn't invalidated, races between a write and a concurrent read repopulating the cache, and ordinary expiry all still require defensive correctness (bounding cache TTL by mapping expiry, treating the database as authoritative on any doubt). See Architecture Deep Dive → Cache Hierarchy and Cache Expiry Correctness.

Analytics collection adds work on every redirect. How and where that work happens has real consequences for redirect latency and database health, and the design must state explicitly whether analytics loss is acceptable.

The URL mappings table has a simple schema and a single dominant access pattern — primary-key lookup by short code — which narrows, but does not eliminate, the database decision.

Whether the same long URL should always produce the same short code is a genuine product decision, not an automatic optimization — and it is missing from a purely technical design discussion.

If global deduplication is required, define precisely which fields participate in the identity check (e.g. long_url alone, or long_url plus owner_id) rather than blindly enforcing uniqueness on a raw URL hash — different owners, campaigns, or expiry policies for the same destination are common, legitimate product requirements that a naive dedup rule would break.

Uniqueness and predictability are separate concerns and deserve a separate decision — treating Snowflake-vs-sequence as the answer to enumeration conflates the two.

Once a request misses the cache, it must read from somewhere authoritative — and whether that read goes to the primary or a replica is its own trade-off.

Eager cache population immediately after a successful write makes the replica-staleness window rare in practice — most reads for a brand-new mapping are served from cache before they would ever reach a replica. The residual risk is a cache miss (eviction, cold start, or population failure) landing on a replica that has not yet replayed a very recent write. See database scaling for the general read-replica mechanics, Architecture Deep Dive → Database Access & Indexing, and Failure & Scale → Read Replica Lag for how this is detected and mitigated.