Shorten.it

Login Page
System Architecture
Prometheus Dashboard
Discord Alert
eMail alert

Inspiration

Four students from Montreal, Quebec. Two attending University of Waterloo and two attending Concordia University - Montreal. After countless rejections for Summer 2026 Internships, we wanted to push ourselves 1 LAST TIME by attempting a different type of hackathon, more specifically this Production Engineering Hackathon ran by Major League Hacks.

What it does

This is the most scalable, reliable and guaranteed to wake up the on-call engineer url-shortner of all time. Simply provide the link you want shortened and your results will be ready within second. The greatest part about this URL-Shortener is that it is bullet proof, carefully encoded using our Base62 hashing algorithm and our armored setup, you can send over 100 req/s and our service will still be online.

How we built it

Next.js frontend that proxies API requests through an Nginx load balancer to four Flask app instances, backed by PostgreSQL (pooled connections) and Redis (LRU cache for redirect lookups), with a full observability stack (Prometheus, Grafana, Loki) collecting metrics and logs via node/process exporters, an OTel collector, and Promtail. The redirect flow is optimized with a cache-first strategy, checking Redis for url:{code} before hitting PostgreSQL, then caching the result with a 1-hour TTL before issuing the 302 redirect

Challenges we ran into

Caching Problem One example problem we faced was during scalability testing where we were faced with too many cache misses, requiring us to visit the main Postgress database. Thanks to our test logs which displayed the cache miss and hit percentages, we were able to decrease the misses from 30% to 15%.
Latency Problem When stress testing our architecture, we originally had a single instance which ended up causing a lot of latency when we had a lot of requests at once. We knew that one of the ways to decrease latency under load would be to scale horizontally, so we set up tests to track latency with 1 instance, 2, 3, 4, and 5 instances, and 4 instances performed the best. We were able to track and confirm this thanks to our metrics, allowing us to implement a robust solution.
Malformed Data One of the problems we had was with malformed data and we would get a lone error message. When fixing that problem we didn't yet have logging, but now we get warning in our logs. We were able to find there was a problem by adding unit tests, but having logs earlier would have helped pinpoint the issue faster.

What we learned

Something we asked ourselves was if users try to hash the same website multiple time, or if a website was already hashed should we generate a new code?

Since users can modify what url the generated code points to, we decided that, yes, we would generate the code each time, so there's no point in even checking the database for existing instances to save time. The endpoint would just generate the new code and allow duplication if the user causes it.