A short link that stays put.

A short-link service has a small visible surface and a surprisingly important record behind it. A useful link needs to keep working after the process restarts. Repeated requests for the same destination should not create a pile of unrelated codes, and concurrent clicks should not overwrite one another’s counts.

Teams that need a simple self-hosted link service or a small link-shortening API inside another product.

We built a service that accepts a web URL and returns a six-character code. Visiting the code redirects to the original address. A separate stats endpoint returns the destination, creation time and hit count.

The interface rejects missing, malformed and non-web addresses. Shortening the same URL again returns the same code. An unknown code receives a clear not-found response. Links and counts live in a persistent database rather than an in-memory map.

The request handler passes the work through validation and a service layer into persistent storage. Keeping those responsibilities separate makes the small API easier to reason about: accepting a request, deciding what it means and saving it are distinct jobs.

A redirect increments the stored count in one database operation. That avoids reading a value into the application and later writing an out-of-date total over someone else’s click. The database configuration allows concurrent access to wait briefly rather than fail immediately on a busy write.

The hard part is preserving a simple contract under repetition and interruption. Idempotent shortening means the same input keeps its code. Atomic counters keep concurrent visits from losing counts, and persistent storage keeps the saved records available when the service reopens.

The server drains in-flight requests during a graceful shutdown, with a window of up to 15 seconds. The scope stays intentionally small: create a link, follow it and inspect its count. Each part has a clear response when a request is invalid or the code cannot be found.