URL Shortener with Click Analytics and a Load Test Report
A URL shortener looks like a weekend project until you ask what happens at a few thousand redirects per second: how codes are generated without collisions, how clicks are counted without slowing the redirect, and how one abusive client is stopped from filling the database. Build one, then load test it and write up the numbers. The written report on caching, indexing and p95 and p99 latency is what turns a small app into a solid final year project.
Beginner
Achievable by one student in a semester with familiar tools.1 semester · 2 students
7 to ship
4 optional extrasSuggested stack
What you should ship
- A link creation API with custom aliases, expiry and documented request and response formats
- A redirect endpoint backed by an indexed PostgreSQL table and a Redis cache for hot links
- Click analytics recorded asynchronously by a worker, with a dashboard per link
- Token bucket rate limiting that returns 429 with a Retry-After header
- k6 load test scripts committed to the repository and runnable with one command
- A performance report with p50, p95 and p99 latency and throughput before and after each optimisation
- Tests covering code collisions, expired links and rate limit behaviour
If you have time left
- Checking destination URLs against a malicious URL list before accepting them
- QR code generation for each short link
- A second application instance behind a load balancer, with the report extended to show the effect
- Bot filtering so crawler traffic is excluded from click counts
Problem
Short links are everywhere: society posters, SMS campaigns, QR codes on flyers. The product is simple, which makes it a good place to learn what a backend does under load. Most student versions stop at "it works on my laptop" and never measure anything.
What you build
- An API and a small web interface to create short links, with optional custom aliases and expiry dates.
- A redirect endpoint that is as fast as you can make it.
- Click analytics per link: clicks over time, referrer, coarse country from the IP address, and device type.
- Rate limiting on link creation per API key and per IP address.
- A load test suite and a written performance report.
Suggested architecture
- Code generation: compare two approaches in your report, for example a counter encoded in base62 against random codes with a collision check. Explain which you chose and why.
- Redirects: decide between 301 and 302. Browsers cache a 301, which is faster but means you stop seeing repeat clicks. That trade-off belongs in the report.
- Storage: PostgreSQL with an index on the short code. Measure the redirect with and without that index on a table of a few million rows.
- Cache: Redis in front of the lookup for hot links, cache-aside with a TTL.
- Analytics: never write a click row inside the redirect request. Push click events onto a Redis stream or a queue and have a worker insert them in batches.
- Rate limiting: a token bucket in Redis, returning 429 with a Retry-After header.
- Load testing: k6 scripts run from a separate machine, reporting p50, p95 and p99 latency, throughput and error rate.
Milestones by month
- Month 1: API, code generation, redirects, database schema, and a seed script that creates a few million links.
- Month 2: analytics pipeline with a worker, dashboard charts, rate limiting.
- Month 3: load test baseline, then add the index, the cache and batched analytics one at a time, measuring after each change.
- Month 4: deployment, abuse checks, report and demo.
How it will be assessed
- The performance report: a table showing latency and throughput after each change, run on the same hardware with the same script, and a short explanation of each result.
- Whether the redirect stays fast while the analytics worker is under load.
- Tests for code collisions, expiry and rate limiting.
- A clean, documented API.
Pitfalls
- Changing two things between load test runs, so you cannot tell which one helped.
- Running the load generator on the same machine as the server.
- Reporting averages only. Averages hide the slow requests that users notice, so report percentiles.
- Ignoring abuse. A public shortener gets used for phishing links within days. Keep link creation behind sign-in or add a blocklist check.
Ideas and guidance, not finished projects
These are project ideas and scoping guidance, published free for students to use as a starting point. I do not build, write, or sell final-year projects, and I do not complete coursework for anyone. Take an idea, make it yours, and build it.
Not sure this one fits you?
I help students pick an idea that matches their skills and their deadline, then scope it down until it is finishable. Guidance only, never done for you.
Stuck on something specific?
Writing only gets you so far. If you want an answer to your situation rather than the general case, book a session and we will work through it together. Sessions are free for approved Sefism members, and a few slots open each week.
Follow along
New writing, resources and project ideas land here first.