URL shortener walk-through: key generation, redirect status and abuse controls

Goal

Turn a long URL into a short key that redirects reliably, can be switched off, and does not become an open relay for abuse.

Prerequisites

A decision on who may create links (authenticated users, or anonymous with limits) and whether a target may change after creation.

Steps

1. Constraints: redirects must stay fast and available even when creation is down; keys must be short but not enumerable in bulk; any link must be revocable. Decide whether clicks are counted.
2. Components: a creation API; a key store; a redirect handler behind a cache; an abuse check at creation (scheme restricted to http and https, target resolves to a public address, blocklist lookup); an admin path that disables a key and purges the cache.
3. Data model: link(key, target, owner, created_at, expires_at, disabled_at) with the primary index on key and a secondary on owner; optional click(key, at, referrer_class) written asynchronously from the redirect path.
4. Key generation: random base62 of fixed length, retried on collision (seven characters give 62^7, about 3.5 trillion keys); a counter encoded in base62 is shorter but lets anyone walk every link. Custom aliases live in a separate namespace with a stricter character set and a review of impersonation.
5. Redirect status: RFC 9110 defines 301 (Moved Permanently) as telling the client that future references ought to use the new URI, whereas 302 (Found) says the client ought to continue using the original URI. A permanent redirect can therefore be remembered by clients and bypass the service, so use 302 or 307 whenever counts or revocation matter, and 301 only for links that will never change. Add Cache-Control: no-store if clicks are counted.
6. Failure modes: cache serving a disabled link (invalidate on disable, short TTL as a backstop); store outage (a read replica or an edge cache serving stale entries); phishing targets (report endpoint, reputation lookup, per-owner creation limits); loops back to the shortener's own domain (reject at creation); enumeration (random keys, uniform 404 responses, lookup rate limits).
7. Measure: redirect latency at the tail, cache hit ratio, 404 rate as an enumeration signal, creations per owner per hour, disabled links per day, time from abuse report to disable.
8. Not first: analytics dashboards, custom domains, QR codes, link previews, split targets, bulk-creation API keys.

Expected result

A redirect touches at most one cache and one store, a link can be turned off within seconds, and abuse is bounded by creation limits rather than by manual review.

Limits and test basis

Proposed design, no measurements. The 301 versus 302 choice is hard to reverse once clients have cached permanent redirects, so it should be made before launch.