UCAM Cloud

The problem

Before UCAM Cloud, UIU's existing university portal could not keep up with registration windows. Thousands of students tried to select sections at the same time, the portal slowed to a crawl or went down, and what should have been a quick task often became a five-to-six-hour ordeal of refreshing and waiting, sometimes ending with the sections a student wanted already gone.

Replacing that portal was not an option: it runs the university's day-to-day academic operations. The job was an independent registration system that could take the full spike on its own and stay in sync with the portal.

What I built

I joined Edusoft Consultants in October 2024 and took end-to-end technical ownership of building UCAM Cloud from scratch. I built the first production version in three months, from October 2024 to January 2025: its architecture, backend services, transactional seat allocation and cloud infrastructure. It launched for the January 2025 registration window, and I have developed it continuously since; bot detection, for one, came in 2026.

I designed, built, and continue to operate UCAM Cloud, with sole human code contributions across its backend and portal repositories. The platform operates independently of UIU's existing university portal, with integration and coordination across the broader university system, including work alongside Saikat Sikdar. The current backend codebase dates from April 2025; in February 2026 I rebuilt the student and admin portal on a new stack as registration demands grew.

Engineering decisions

Correctness lives in the database

A seat is granted by a conditional write in DynamoDB that succeeds only while the section still has capacity (and, where seats are split between departments, while the department's share does). Two students racing for the last seat cannot both win: one write succeeds and the other gets "section full". A repeated tap finds the seat already held and gets "already selected", so a retry never takes a second seat. The availability check before the write and the counts on the live board are there for speed and display; the database has the final word.

Built for the worst minute, not the average day

Most of the year the platform is close to idle. A selection window opens about three times a year for a day or two, and the load arrives as a wall the moment it unlocks. The platform scales up for the window and back down when it closes, so it holds the opening minute without paying for that capacity the rest of the year.

A live seat board that is allowed to fail

Students watch seat counts change in real time over WebSockets. The realtime server I built for it runs on a single 2 vCPU, 8 GiB machine that serves production and staging together, and it is configured for up to 40,000 connections per node. New connections are admitted at a controlled rate, and deploys hand clients back gradually over 45 seconds instead of dropping everyone at once.

Its failure boundary is deliberate: section selection never waits for it or depends on it. If it goes down, the board goes dark and students can still select and register.

Bot detection: fewer requests beat faster requests

A large part of the spring spike was not students but scripts hammering selection before it opened. Between spring and summer I added a login challenge and a bot-detection system for section selection. On the same departments' wave, the busiest minute fell by 75%, from 788,816 to 194,619 requests, and the wall of scripted requests before the opening largely disappeared. (Summer cohorts are also smaller, which accounts for part of the drop.)

Works alongside the university's existing system

UCAM Cloud is not a replacement for UIU's main university portal. I built it as an independent registration platform that handles high-concurrency section selection while synchronizing with the existing academic system. That isolates registration traffic without requiring the university to replace its core infrastructure: the work was improving registration under a constraint, not rewriting the system around it.

The portal stays the system of record, and its code did not have to change. UCAM Cloud syncs the data it needs, hands registrations back and cross-checks the two; during a window it runs section selection on its own, so the portal never takes the spike.

Backups that can be trusted before they are needed

Admins can back up everything section selection depends on for one department and term to cloud storage, as raw records so every field comes back exactly as stored. Each backup carries a checksum, so a truncated or altered file is rejected on read.

Restoring is guarded: it first shows a dry-run diff against live data, it will not run during an open selection window unless forced, and it takes an automatic backup of the current state before writing anything. Both run as background jobs, since a whole department is too large for a single request.

The outcome

The difference showed in the first window. UCAM Cloud launched for the January 2025 registration window, with no downtime observed during the launch. A registration that used to take five to six hours now takes most students under a minute, with nearly all the sections they wanted. These are observed outcomes from the windows, not a formally timed study.

It has since handled steadily heavier windows. The figures below come from production CloudWatch metrics and selection logs.

Spring '26 (23 Feb): 788,816 requests in the busiest minute, about 13,100 per second averaged over that minute, and 5.65 million in the peak hour, for two departments.

Summer '26 (4 Jul): about 11 million requests over the two busiest days, with a busiest minute of 194,619 (about 3,244 per second). Half of all requests finished in about 15 ms, 90% under 30 ms and 99% in about 127 ms; at the peak minute p99 rose to about 122 ms. 99.95% of requests got a non-5xx response; expected answers such as "section full" count as successful responses. Students claimed 37,096 seats and no overselling was observed: in the selection logs, every "section full" came from a section sitting exactly at its limit.

Trade-offs and lessons

• Validate capacity limits before every window. At the very top of the Summer '26 wave a few students had to tap "select" twice, and a small share of requests took several seconds. The cause: some per-service concurrency caps were still tuned for a traffic ceiling ten times lower. No seats were lost or wrong, but the fix is procedural: check every cap against current capacity in the pre-window run-through.
• Background jobs must never touch a held seat. During the same window, a background sync could clear a student's section record while their seat stayed held. We found the affected records during the window, and for Fall '26 changed the sync so it can no longer write to a record that holds a seat.
• The cheapest capacity is traffic you never serve. A login challenge and bot detection bought more headroom between spring and summer than any tuning would have.

Looking back

UCAM Cloud started as a three-month effort to solve a problem that had frustrated students for years. What made it work was not simply handling more traffic. It was separating registration from the legacy system, protecting seat-allocation correctness under contention, and designing the infrastructure around the university's actual usage patterns.

I continue to develop and operate the platform through each registration window, refining it as traffic, requirements and the university's needs evolve.

Built with

Go · AWS · DynamoDB · Cloudflare

Read more

• Advising day: the afternoon a whole semester picks its seats at onceTraffic, latency, bot defence and the CloudWatch queries
• A realtime seat board that never blocks section selectionHow the live seat board stays out of the way

The source code belongs to the client and is private.