UCAM Cloud

The challenge

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 platform that takes the whole spike on its own and stays in step with the university's system.

My role and timeline

I joined Edusoft Consultants in October 2024 and took end-to-end technical ownership of building UCAM Cloud from scratch. 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.

1. Oct 2024 – Jan 2025Designed and built the first production version in three months. It launched for the January 2025 registration window.
2. Nov 2025 – Feb 2026After the Fall '25 selection day overloaded the database behind the system of the time, rebuilt the selection path around a single guarded write. The rebuilt backend served Spring '26, and in February 2026 I rebuilt the student and admin portal on a new stack.
3. Jun – Jul 2026A live seat board on its own server, a reserved share of capacity for each service, and a login challenge, all in place before Summer '26.
4. Oct 2026Safer sync with the university's system, a cross-check between the two, a per-student request limit, and selection backups (built, not yet needed in a window).

Architecture at a glance

UCAM Cloud is not a replacement for UIU's main university portal. It is an independent registration platform that takes high-concurrency section selection off the existing academic system and stays in sync with it. The university's system stays the source of truth for courses, schedules, student records and final registration; UCAM Cloud owns seat counts and who holds which seat while selection is open.

Three engineering decisions

1. A seat is granted by one guarded write

Invariant: a section never holds more students than its capacity, or than a department's share of it.

When one seat is left, two students can tap Select in the same instant. Application-level locking would bring its own coordination, lock-ownership and recovery problems; a capacity counter in a cache can drift from the committed seat records (I built that design in January 2026 and replaced it before Spring '26). So the database enforces the invariant: the seat record and the capacity update succeed or fail together.

Each selection is one all-or-nothing transaction in DynamoDB: create the student's seat record only if it doesn't exist, and add one to the section's count only while it is below capacity and the department's share. The quick check before it only answers "full" fast; the transaction has the final word. A popular section can still see contention or request failures, but the conditional transaction keeps those conflicts from allocating seats beyond capacity.

• Last seat, two students: one commits; the other sees "section full". Nothing is half-written.
• Double tap: the second request finds the seat record and answers "already selected", never a second seat.
• Confirmed conflict: the transaction is cancelled and no seat is allocated; the student can tap again.
• Timeout or lost connection: the seat may have been committed without the answer arriving. Tapping the same section again is safe: the seat record is keyed to the student and section, so the retry finds it and answers "already selected" instead of taking a second seat. The app never retries a selection on its own.

Result: in every 2026 window, each "section full" that logged a count showed the section exactly at its limit, and none was seen above it. On Summer '26 the database itself refused 2,792 writes the quick check could not catch.

2. Surviving the opening minute

Failure mode: the opening wall exhausts a shared limit and everything fails together.

On Summer '26 the backend went from about 10,000 calls a minute at 12:40 to 115,567 in the minute selection opened.

That failure mode is what happened on Fall '25. The system of the time used a relational database with a fixed connection limit, and every backend instance opened its own connection. At 09:31 the database ran out of connections, stuck requests filled the account's limit of 1,000 concurrent instances, and 39% of the day's requests failed until about 10:20.

The rebuild removed that cliff: selection now runs on a database billed per request, so there is no connection pool to exhaust. Limits still exist (database throttling, transaction contention, service quotas, my own concurrency caps), so each service has its own reserved share of capacity, and a full share turns extra requests away at once instead of letting them pile up behind stuck ones.

Result: server errors fell from 39% on Fall '25 to 0.71% on Spring '26 and 0.064% on Summer '26, with whole-day p99 latency of 136 ms and 115 ms. Nearly all of Summer's errors were requests turned away at a full share, not code failures; the second lesson below covers them.

Bot detection: fewer requests beat faster requests

Part of every opening wall is scripts, not students. Before Summer '26 I added a login challenge that fails closed and an after-the-window bot analysis that flags accounts for review; since October a per-student limit caps how fast one account can hit Select. Summer's busiest hour carried 29% fewer requests than Spring's while placing about a quarter more course seats; cohorts differ between terms, so the challenge doesn't get all the credit.

3. A live seat board that can fail without touching selection

Invariant: selection never waits on, or depends on, the live board.

The tempting design confirms a seat, broadcasts it, then answers, which makes every selection only as reliable as the broadcast. Here the seat is committed first; a snapshot of the section is published after, and a failed publish is only logged. The board allocates nothing, and each update is a full snapshot, so a missed message is fixed by the next.

It runs on its own 2 vCPU, 8 GiB server, configured for up to 40,000 connections, admits new connections at a controlled rate and hands clients back over 45 seconds during deploys.

Trade-off: if the board goes down, it shows "Offline" and selection carries on. Known gap: after a disconnect the last counts stay on screen without a "stale" warning.

Operating alongside the university's system

Course, student and pre-advice data flows in as it changes and through sync jobs before each window; failed jobs are retried, then set aside for review. Selection never waits on that system: if it is down, students keep selecting and only final registration waits.

Registrations flow back, and a course counts as registered only when the university's system confirms it. If it rejects one, nothing is rolled back on either side: the course stays unregistered and the student keeps the seat. The automatic registration run retries a few times, then records each failed or partial student with the courses left and the university's reason, for an admin to resolve; seats still unregistered after the window can be released by an admin clean-up job. Repeats are guarded three ways: courses already registered are skipped, only one automatic run can go at a time, and the university's system answers a repeat with "already registered". Known gap: a permanent rejection and a temporary failure are still retried the same way.

Summer '26 showed where the two can collide: a sync that rebuilt a student's course list could erase which section they held while the seat stayed taken (75 course records, found during the window). In October sync was changed to write only the university's own fields, never a seat holding, and to pause for a department while its window is open. A cross-check page now flags about 25 kinds of mismatch between the two systems for an admin to repair.

Production results

These decisions were tested in real registration windows: one major outage on the earlier architecture, then windows with far fewer errors on the rebuilt one.

The January 2025 launch ran without downtime observed, and most students now finish in under a minute with nearly all the sections they wanted (observed, not a timed study). Every selection day still held in production metrics:

Fall '25 ran on the earlier design and did not log seat counts (—). Fall '26 so far is the EEE wave only; the CSE wave runs later this month.

Measurement notes

• Requests, server errors and latency come from production API telemetry; seat counts come from the selection logs. Each column is one selection day in Dhaka time.
• Requests include automated traffic and the browser's preflight requests. Server errors are 5xx responses as a share of all requests; expected refusals such as "section full" are not errors.
• Course seats placed counts distinct student-and-course pairs with at least one successful selection that day; switching sections counts once. Student numbers are not published.
• "Seen over capacity": every refusal that logged the section's count showed it exactly at its limit, none above. Strong evidence, not proof; no final scan of every section was part of this check.
• Minute-level request metrics are kept for 15 days, so the per-minute chart counts backend calls from the retained logs.
• Registration time (five to six hours before, under a minute after) is observed from operating the windows, not a timed study.

Trade-offs and lessons

• A fixed connection limit is a cliff, not a slope. On Fall '25 the database, not the code, decided how many students could be served. The rebuild took that limit out of the selection path rather than raising it.
• Capacity limits are configuration, and they need testing too. At Summer '26's peak three services reached their reserved share exactly, and 5,123 requests in that hour were turned away. Those rejections reached students as server errors: the day's 5,395 errors (0.064%) track the day's 5,367 rejections hour by hour, while application errors were close to zero. Students could retry, and no incorrect seat allocations were observed in the available production records. Re-sizing every share against measured peak concurrency is on the pre-window checklist; the first Fall '26 wave (EEE only) peaked far below them, and the CSE wave later this month is the next real test.
• Background jobs must never touch a held seat. The Summer '26 sync collision came from a job that treated the university's data as the whole truth. Sync now owns only its own fields.

Looking back

UCAM Cloud began as a three-month effort to solve a registration problem that had affected students for years. Its first production version launched in January 2025, operating independently while staying integrated with the university's existing academic system.

The work didn't end at launch. I continue to develop and operate the platform, adapting its architecture as registration traffic, operational requirements, and the university's needs evolve.

The most important lesson has been that reliable systems aren't built by optimizing for a single traffic peak. They're built by making correctness explicit, isolating failures, and understanding how the system behaves when demand exceeds expectations.

Built with

Go · AWS · DynamoDB · Cloudflare

Questions about UCAM Cloud

What is UCAM Cloud?

UCAM Cloud is the course-registration platform of United International University (UIU) in Dhaka. Three times a year, at each trimester's advising window, UIU students use it to select sections and register for courses.

Is UCAM Cloud the same as UCAM?

No. UCAM is UIU's existing university system, and it stays the source of truth for courses, schedules, student records and final registration. UCAM Cloud is a separate platform that takes the section-selection rush off it: it owns seat counts and who holds which seat while selection is open, and a course counts as registered only when the university's system confirms it.

Where do UIU students log in to UCAM Cloud?

At uiu.ucamcloud.com. This page is a case study about how the platform was built, not the portal. For login or registration problems, the portal lists ucamsupport@uiu.ac.bd; your department office handles seats and sections. Open UCAM Cloud (uiu.ucamcloud.com)

Who built UCAM Cloud?

I did. I joined Edusoft Consultants in October 2024 as a Platform Engineer, designed and built the first production version in three months, and still develop and operate it. It launched for the January 2025 registration window.

Why did UIU section selection use to take hours?

Thousands of students tried to select sections at the same time on the university portal, which slowed to a crawl or went down. Selection often took five to six hours of refreshing and waiting. On UCAM Cloud most students finish in under a minute.

Can two students get the same seat?

No. A seat is granted by one all-or-nothing database write that succeeds only while the section is below capacity. When two students tap Select for the last seat at the same instant, one gets it and the other sees "section full". Tapping again after a timeout is safe: it answers "already selected" instead of taking a second seat.

How busy is UIU section selection?

In Spring '26 the busiest hour carried 3.6 million requests. In Summer '26 the backend took 115,567 calls in the minute the window opened, and the platform placed 27,760 course seats with no overselling observed.

Read more

• Eleven departments, one afternoon: how UCAM Cloud ran UIU's Fall 2026 section selectionFall '26 selection day: 7 million requests, 8 server errors, how long students took
• 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.