QuickPU: One Portal for Punjab University Results (Built for 850 Concurrent Students)

The Problem

Every department at Punjab University publishes results on its own page, on its own URL, with no central index. A student checking their own result has to already know which of those 350+ pages belongs to their department and semester. Multiply that by an entire batch refreshing pages at the same time on result day, and most of campus is just guessing URLs and hammering refresh.

I built QuickPU so that part stops mattering. One search box, one roll number, the right result, regardless of which department published it where.

What I Built

A single search interface where a student enters a roll number and gets their result, no need to know which of the 350+ department URLs to check. Two extra things that made it stick:

• Batch lookup — check up to 200 students at once, useful for class reps and society admins pulling whole-section results in one go instead of one roll number at a time
• PDF export — download the result instead of screenshotting it

Live: quickpu.vercel.app/portal

Architecture

• Frontend: Next.js + TypeScript + Tailwind, with a results dashboard showing GPA per semester so a student can see their trend across the degree, not just one isolated number
• Backend: FastAPI, responsible for fetching and normalizing results on demand
• Database: MongoDB, caching parsed results so repeat lookups for the same roll number don't re-hit the source pages
• Hosting: AWS EC2

The university doesn't expose results through any API, so the backend fetches and parses the actual department result pages per roll number, then normalizes the output into one consistent shape before it ever reaches the frontend. The 350+ department pages don't share a single layout, so the parsing layer is built around per-department patterns rather than one universal scraper, falling back to a generic parser for pages that don't match a known format.

Why this stack

FastAPI over a Node backend here because the scraping and parsing logic is the actual core of the app, and Python's ecosystem for HTML parsing is faster to write and easier to extend per-department than rolling the same in JS. EC2 instead of a serverless platform because result day traffic needed a backend that stays warm and holds DB connections instead of cold-starting under a spike, and because the scraping jobs needed more control over timeouts and concurrency than a typical serverless function allows.

Hard Parts / What I Learned

Result day is the actual stress test, everything else is calm by comparison. The first thing to buckle under the spike was the database connection pool, MongoDB connections got exhausted faster than expected once concurrent lookups multiplied past a few hundred. The second issue was that fetching department result pages at scale started getting slow and occasionally timing out, since I was now generating that same load against the university's own servers that students were generating manually.

The fix on the day was tightening connection pooling and adding request queuing so spikes got smoothed out instead of all hitting MongoDB and the source pages at once, plus bumping the EC2 instance up to handle concurrent request volume properly. Caching parsed results in MongoDB also meant that once a roll number had been looked up once, repeat hits (which happen a lot, since people refresh) didn't need to re-fetch from the source at all.

If I were rebuilding result-day infrastructure today, I'd add a proper queue (something like a lightweight job queue in front of the scraping layer) so spikes get absorbed and processed in order, instead of leaning entirely on connection pool tuning and caching to survive the burst.

Results

• 850 concurrent users on result day
• 4,100+ API hits
• Still used every semester by students across departments

Try It / Links

• Live: quickpu.vercel.app/portal
• Stack: Next.js, TypeScript, Tailwind CSS, FastAPI, MongoDB, EC2