Skip to content
CirruSoul

How a placement-test platform keeps its timer honest

Timed tests only mean something if the clock cannot be gamed. Here is how we built the timer, the leaderboard and the prize list for CirruSoul Arena.

CCirruSoul Technologies Team4 Nov 20263 min read
Engineering

How a placement-test platform keeps its timer honest

Timed tests are only fair if the clock is fair. When we built CirruSoul Arena, a practice platform where IT students sit role-wise tests and compete on a university leaderboard, the first rule we wrote down was simple: the browser may display time, but it never decides it.

The timer lives on the server

When a student starts a test, the server creates an attempt and stores a deadlineAt timestamp. The page shows a countdown, but that is only a picture of the stored deadline. If someone pauses the tab, edits the page or changes their computer's clock, the real deadline does not move.

Two small details make this robust:

  • A sweeper closes expired attempts. Every 30 seconds a job looks for attempts past their deadline and closes them, so a student who simply walks away does not leave an open attempt behind.
  • The server rejects late answers. An answer that arrives after the deadline is not scored, even if the student's own screen still showed time left.

The student's screen is also kept honest in the other direction. The page fetches the server's time on load and works out the offset, so a laptop with a wrong clock still shows the correct countdown.

One rule for ranking

A leaderboard is only trusted if people can explain it in a sentence. Ours is: your rank is the sum of your best ranked attempt in each test, and ties are broken by total time. Retakes for practice never push you down, and only ranked attempts count.

Redis for the board, Postgres for the truth

Leaderboards are read far more often than they change, so they live in Redis sorted sets, which return a sorted slice instantly. But Redis is a cache here, not the record. Every attempt and score is stored in PostgreSQL, and the board can be rebuilt from it at any time. If Redis is ever flushed or replaced, nothing is lost; we run the rebuild and the boards come back.

The prize list is a filter, not a second system

Prizes are for students with an active Season Pass. Instead of maintaining a separate prize ranking, the prize list is the same board filtered to pass holders. One ranking, two views, no chance of the two drifting apart.

Prices come from the server too

The same thinking applies to payments. The amount to charge is always read from the plans table on the server, never from the request, so changing a value in the browser cannot change what a student pays.

What we would tell another team

  1. Decide who owns the truth for each number (time, score, price) and make it the server.
  2. Keep derived views, like leaderboards, rebuildable from the source records.
  3. Prefer one simple ranking rule over a clever one.

If you are planning a test, assessment or competition platform and want a team that has already worked through these details, tell us about it.

  • #Architecture
  • #Redis
  • #PostgreSQL
  • #EdTech
  • #Arena