EASYwalkthrough
301 vs 302 Redirects
This is the single most common follow-up question in a URL shortener interview: should the redirect be a 301 or a 302? The constraint is that we cannot optimize for both analytics accuracy and infrastructure cost at the same time.
A user who clicks the same short link 10 times generates only 1 server hit because the browser remembers the destination after the first request. A 302 (Found) tells the browser the redirect is temporary, so all 10 clicks reach our server.
“A 301 (Moved Permanently) tells the browser to cache the mapping locally.”
We chose 302 as our default (not 301) because our product requires accurate click analytics. With 302, every click passes through our servers, giving us precise click counts, geographic data, and referrer tracking.
Trade-off: we accept higher server load (all repeat clicks hit our infrastructure) in exchange for complete analytics fidelity. If analytics were not a core feature, we would choose 301 and cut server load by up to 60% on popular links. Bitly uses 301 by default for performance because most enterprise customers care about fast redirects, but offers a 302 option for customers who need precise campaign analytics.
Implication: the choice affects infrastructure sizing directly. With 302, we must provision for the full click volume including repeat visitors.
With 301, we provision for unique visitors only. What if the interviewer asks: can we use 301 and still track clicks?
We could use JavaScript redirects or tracking pixels, but both add latency and fail when JavaScript is disabled. Server-side 302 is the only reliable method for complete click tracking.
Related concepts