What a redirect service looks like if you build it yourself

The core is genuinely small

Look up a key, return a 302 with a Location header, write a click record. A competent developer builds a working version in a day. This is why so many teams start down this path, and why the estimate is always wrong: the redirect is perhaps five percent of the work.

Storage and caching

Slug-to-destination is a key-value lookup with a very high read-to-write ratio, so an in-memory cache in front of a durable store handles almost all traffic. The interesting question is invalidation: when someone edits a destination, how quickly does every instance stop serving the old one? Publish-subscribe invalidation or a short TTL both work; silently stale caches after an edit are the failure users will notice.

Click recording must never block the redirect

Writing analytics synchronously ties your response time to your database. Buffer click events in memory and flush them in batches, or push them to a queue. Accept that a crash loses the buffer; a few lost clicks matter far less than a redirect that takes 300 milliseconds because the analytics table is locked.

Custom domains are the hard part

Supporting arbitrary customer hostnames means automated certificate issuance, renewal, and a way to serve the right certificate for a hostname you learned about a minute ago. It means handling validation failures, CAA records, domains that point at you and then stop, and certificates that expire while nobody is watching. This subsystem is larger and more failure-prone than everything else combined.

Availability expectations are unusual

A short link that fails does not degrade gracefully; the user sees an error page instead of the destination, and if the link is on printed material you cannot correct it. That pushes you toward multi-region deployment, health checking and a static fallback path, which is a different operational posture from a typical internal service.

Abuse handling arrives whether you plan for it or not

Any redirect service reachable from the internet will eventually be used to launder malicious destinations, and your domain's reputation is the collateral. You need destination scanning, rate limits on creation, a way to disable a link quickly, and someone to receive abuse reports. Blocklist providers do not care that you are a small internal tool.

When building is the right call

It makes sense when redirects must run inside your own network, when regulatory constraints prevent click data leaving your infrastructure, or when the redirect logic is genuinely bespoke. It rarely makes sense purely to save a subscription, because the recurring cost is engineering attention, and that is the expensive resource.