Building Our Own URL Shortener

Building Our Own URL Shortener

Every blog has outbound links, and over time those links become unwieldy. Long query strings clutter posts, analytics tracking links look suspicious, and leaning on third‑party shorteners introduces dependencies and potential privacy leaks. If you are serious about building a sustainable project, handing over control of your URLs to someone else is a liability. A short link is part of your brand identity: readers should trust that a click on a link takes them somewhere intentional. This is why we decided to build our own URL shortener, end‑to‑end, on infrastructure we control.

At first glance, it might seem trivial. After all, you could spin up a small database and map short slugs to long targets. But when you peel back the layers, you discover this is the perfect “small but serious” systems problem. We need to think about collision‑free ID generation, scalable persistence, cache poisoning prevention, TLS certificates, and fast global delivery. A naïve implementation works fine for a toy project, but our goal is something production‑worthy that can run under https://go.codequesthub.io/ and serve both our own blog and potentially future projects.

We chose Rust for the core logic because of its safety and performance. With cargo-lambda we can compile to an AWS Lambda binary, which makes our compute lightweight, cheap, and inherently scalable. The persistence layer is DynamoDB, configured with on‑demand billing and TTL expiry so links can be short‑lived if needed. API Gateway provides a clean interface for both creating and resolving links. CloudFront sits in front, caching 301 redirects globally so readers experience sub‑second redirects no matter where they are.

The flow is simple: a client sends a POST to our API to create a short link, and then readers resolve it with a GET to the short domain. For example, creating a link looks like this:

curl -X POST \
  -H 'Content-Type: application/json' \
  -H 'Authorization: Bearer $TOKEN' \
  -d '{"target":"https://codequesthub.io/"}' \
  https://go.codequesthub.io/v1/links

and resolving it is as natural as visiting:

curl -i https://go.codequesthub.io/YMK33D

with the server returning a 301 redirect and a Location: https://codequesthub.io/ header. Behind the scenes, DynamoDB stores the mapping, Lambda ensures we never generate the same slug twice, and CloudFront caches the response to avoid hammering the origin. We also paid attention to security at the edge. Rather than forwarding arbitrary headers to API Gateway (which could allow cache poisoning), we configured CloudFront to forward nothing for redirect paths. For the control plane under /v1/*, CloudFront forwards only the headers required (Authorization and Content-Type) so we can perform authentication without exposing ourselves to header‑based cache attacks.

Security does not stop there. We wanted to ensure that link creation could not be abused by anyone who discovered the endpoint, so we added a bearer token requirement for all POST /v1/links calls. The token is generated once, stored in AWS Secrets Manager, and injected into the Lambda environment at deploy time. This means the function never calls Secrets Manager at runtime, but always has the correct token available in memory. If a request lacks the proper Authorization: Bearer <token> header, it is rejected with a 401 Unauthorized. To further protect the endpoint, we added a CloudFront‑scoped WAF rule that rate‑limits traffic to /v1/*, blocking any client that exceeds a defined threshold.

The result is already live and working: a short domain we control, redirects that are fast and globally cached, and an API surface that is both minimal and secure. All of the code, Terraform configurations, and build scripts are available in our GitHub repository: github.com/professorbyte-codequest/quickshort-rs.

This is only the beginning. In upcoming posts we will add features like an authenticated admin console for managing and inspecting links, analytics pipelines for tracking visits, and security headers like HSTS for even stronger guarantees. A URL shortener may start as a convenience, but built properly it becomes an important part of your publishing platform. By owning the infrastructure and the code, we are building a foundation we can trust and extend.