Remote Proctoring at Scale: Engineering Trust Into High-Stakes Exams
Most software has to work. High-stakes assessment software has to be trusted — by exam candidates whose careers depend on the result, and by certification bodies whose credibility depends on the process being defensible. Architecting TestReach’s core systems taught me that trust, in this context, is an engineering property, not a marketing claim.
Uptime during the exam window isn’t a metric, it’s a promise. A five-minute outage on a typical SaaS product is an inconvenience. A five-minute outage during a scheduled professional certification exam is a candidate’s exam attempt in jeopardy, and potentially a compliance issue for the certification body. We architected for exam-day traffic spikes specifically — load-balanced infrastructure sized not for average load, but for the predictable, calendar-driven spikes that come with scheduled exam windows across time zones.
Every integration is a trust boundary. APIs and third-party integrations for global certification workflows mean TestReach sits in the middle of multiple institutions’ compliance requirements simultaneously. A schema change or API contract break isn’t just a bug — it can cascade into a certification body’s own audit trail. We treat every external integration as a contract that has to be versioned and defended, not just a convenient data pipe.
Remote proctoring lives or dies on graceful degradation. Network conditions for exam candidates vary enormously — this is a global candidate base, not a controlled testing center. The system has to distinguish between “candidate’s connection genuinely indicates a problem” and “candidate is on a slower but legitimate connection,” without either compromising exam integrity or unfairly flagging honest candidates. That’s a harder engineering problem than raw uptime, because the cost of getting it wrong falls directly on a real person’s exam outcome.
Scale reveals whether your reliability engineering was real or theoretical. It’s one thing to design for millions of exams delivered globally on a whiteboard. It’s another to have actually done it, across certification bodies like ACCA, British Council, and CIPS, and have the delivered exam count to show for it. Reliability claims that haven’t been tested at real scale, under real exam-day load, are just architecture diagrams.
The lesson that’s traveled with me into every other project since: when the cost of failure lands on someone else’s life outcome rather than your own metrics dashboard, the engineering bar isn’t “does it usually work.” It’s “have we made failure genuinely rare, and made the failure mode honest when it happens anyway.”