system 2026

SafeExam.in

Next.js, FastAPI, PostgreSQL

Browser-based institutional examination platform with activity monitoring, tab-switch detection, and asynchronous answer auto-save.


Overview

SafeExam.in is a production-grade browser-based examination platform designed for institutional use. It eliminates the need for dedicated exam management infrastructure by providing a secure, lightweight, and user-friendly interface for conducting MCQ assessments online.

Key Features

Client-Side Proctoring

  • Tab Switch Detection: Monitors browser focus and detects when students switch tabs or windows during the exam
  • Activity Monitoring: Tracks mouse movements, keyboard inputs, and window focus events
  • Real-time Signals: Captures and logs proctoring events for post-exam review

Network-Resilient Architecture

  • Asynchronous Auto-Save: Automatically persists answers every 30 seconds to backend, regardless of network conditions
  • Offline Support: Maintains local answer cache so students never lose work during connection drops
  • Graceful Recovery: Automatically syncs answers when connection is restored

Performance & UX

  • Optimized Load Times: Client-side rendering with strategic code splitting
  • Progressive Enhancement: Works with or without JavaScript for maximum accessibility
  • Responsive Design: Works seamlessly on desktops, tablets, and mobile devices

Technical Stack

  • Frontend: Next.js 14, TypeScript, React Hooks for state management
  • Backend: FastAPI for lightweight async HTTP server
  • Database: PostgreSQL with optimized queries for exam result aggregation
  • Infrastructure: Deployed on Vercel (frontend) with managed PostgreSQL

Real-World Usage

  • Regular deployment: ~50–60 students per test
  • Approximately 7–8 institutional assessments conducted
  • College infrastructure allocation: ₹20,000

Impact & Results

  • Enables institutions to conduct secure online assessments without expensive proctoring software
  • Reduces server load through intelligent client-side caching and async updates
  • Provides audit trail of student activity for institutional compliance
  • Demonstrates understanding of real-world capacity limits

Learning from Production Reality

The Incident

During a multi-lab deployment, approximately 150+ students were given exams simultaneously across four campus labs. The system encountered a database connection-pool bottleneck and limited concurrent access.

What happened:

  • Database connection pool was configured: size 30, overflow 70 (adequate for typical 50-60 concurrent use)
  • Actual concurrent requests: 150+ students across multiple labs
  • Result: Pool exhausted; subsequent requests queued for available connections
  • Student impact: Some experienced delays accessing exam interface; no data loss occurred

Why this mattered: The system had been tested with 50–60 students and handled it perfectly. The jump to 150+ exposed an architectural assumption I hadn’t questioned: “works in testing” ≠ “works at real-world scale.”

What Changed

  1. Connection pool parameters — Increased size and overflow based on observed load
  2. Monitoring — Added real-time tracking of concurrent connections
  3. Understanding — Learned that reliability is an architectural feature, not something you bolt on after the fact

The Lesson I Carry

Systems fail when real usage patterns meet untested assumptions. That failure was instructive. It changed how I think about:

  • Scalability: Not “how many can it theoretically handle?” but “do we know the limits and are we honest about them?”
  • Reliability: Not “nothing crashed” but “does it degrade gracefully when over capacity?”
  • Production readiness: Testing in isolation teaches you about code. Production teaches you about reality.

Current State

SafeExam now operates with clear understanding of its capacity and behavior under load. The incident made it better—not perfect, but honest about what it can do.

Development Timeline

Started: February 2026
Status: Active Development
Team: Solo developer with institution collaboration

Frequently Asked Questions

Q: Is exam data secure and encrypted? All answers are transmitted over HTTPS. Database queries are parameterized to prevent injection attacks. Student data is isolated per exam session.

Q: What if a student loses internet connection mid-exam? Answers are auto-saved every 30 seconds locally. When connection returns, they sync automatically. No work is ever lost.

Q: How do you detect cheating/tab switching? We log tab switch events and window blur events. Proctors can review the activity timeline post-exam but cannot intervene in real-time.

Q: What browsers are supported? Chrome, Firefox, Safari, Edge (last 2 versions). Mobile browsers work but aren’t recommended for exams due to smaller screens.

Q: Can students download the exam questions? No. Questions are served dynamically and not cached. Screenshots and downloads are blocked via JavaScript.

Q: What’s the maximum number of concurrent exam takers? The last documented deployment involved 150+ students and exposed database connection-pool limits. The case study describes the incident and changes made afterward; it does not claim a newly verified maximum capacity.

Building a robust proctoring system requires understanding hardware bottlenecks and optimization, similar to the challenges explored in our Quantum Computing research paper. Both focus on scalability, reliability, and ensuring systems work under real-world constraints.

[This Space Intentionally Left Blank]

The bottom of every page is padded so readers can maintain a consistent eyeline.