The Question
FE Design

Design a High-Concurrency Online Examination Frontend Platform

Design the frontend architecture for an enterprise-grade Online Examination Platform supporting up to 10,000 concurrent students. The system must operate under unstable network conditions with absolute zero data loss, feature aggressive client-side anti-cheating mechanism (proctoring, tab tracking, and keyboard lockout), load complex multi-media exams instantly, and support deep offline-first capability. Explain how you would structure component hierarchies, implement secure client-side storage, guarantee synchronized updates under heavy load, and optimize rendering interfaces to achieve continuous responsiveness and high accessibility.
React
Tailwind CSS
Zustand
IndexedDB
Web Cryptography API
Beacon API
Web Workers
REST
Questions & Insights

Clarifying Questions

What types of questions must the Online Examination Platform support for the Minimum Viable Product (MVP)?
Assumption: The MVP will support single-choice (radio), multiple-choice (checkbox), and short-text questions. Complex rich-text editors, file uploads, or code compilers are out of scope for the MVP.
How should we handle intermittent or complete network disconnects during an active exam?
Assumption: The system must operate on an offline-first architecture during the examination. Answers must be persisted locally instantly and synced asynchronously in the background. The user must be able to continue testing uninterrupted during a network drop.
What level of proctoring and security monitoring is required for the MVP?
Assumption: We require passive client-side proctoring. This includes logging browser tab switching (blur/focus events), detecting copy-paste attempts, blocking context menus, and enforcing fullscreen mode. Active AI-based webcam video streams are out of scope, but periodic webcam snapshots are required.
What is the expected scale of concurrent test-takers per exam session?
Assumption: The frontend must scale to support up to 10,000 concurrent students per exam. To prevent DDOSing the server at the start or end of an exam, the frontend must implement staggered resource pre-fetching and batched write operations.
---

Crash Strategy

Core Bottleneck: Preventing data loss during high-stakes testing under volatile network conditions, while protecting the integrity of the exam content and minimizing backend server load.
Progressive Architectural Questions:
Reliability: How do we guarantee zero data loss of user answers? Strategy: Client-side local persistence using IndexedDB, wrapped in an append-only transaction queue.
Security: How do we protect downloaded exam questions and local answers from manipulation? Strategy: In-memory question decryption via the Web Cryptography API and client-side storage encryption.
Performance & Scaling: How do we handle large exams (e.g., 200+ multi-media questions) without causing browser stutters or network congestion? Strategy: Lazy-loading of question assets, virtualizing the question navigation panel, and batching debounced state synchronization.
Telemetry: How do we reliably record and report cheating behaviors without interrupting the student's train of thought? Strategy: Buffering telemetry events and flushing them via Beacon API or background fetch.
---

Elite Bonus Points

Web Cryptography API (Local Sandbox Encryption): Locally stored answers in IndexedDB are encrypted using an AES-GCM key derived on-the-fly from the user's session token. This prevents users from inspecting or modifying their local answers via DevTools.
Navigator.sendBeacon for Telemetry: Tab switches, fullscreen exits, and copy-paste events are flushed immediately using navigator.sendBeacon to ensure telemetry is safely delivered even if the user abruptly closes the browser.
Double-Buffer Network Queue with Backoff: An in-memory queue that drains to IndexedDB on failure, utilizing exponential backoff with randomized jitter to synchronize answers to the API without overloading the backend during peak times.
CSS Painting & DOM Protection: Utilizing CSS properties (user-select: none, pointer-events) and keydown interceptors to block standard inspector shortcuts, printing, and clipboard leakage.
---
Design Breakdown

Design Summary

Concise Summary

A highly robust, offline-first client-side single page application built around a secure state machine. It guarantees exam integrity and 100% data durability using local IndexedDB caching, client-side encryption, and a prioritized background synchronization engine.

Major Components

AppShell: Root container providing theme providers, global alert portals, and the base app container.
ExamLayout: Split-view UI container handling the header (metadata, timer), the side navigation pane, and the main canvas.
SystemCheckPage: A step-by-step wizard checking system hardware, network connectivity, and browser security permissions.
ExamWorkspacePage: The dynamic core view managing the active question rendering, progress updates, and layout-to-data bindings.
QuestionViewer: A polymorphic leaf engine rendering questions securely based on their metadata type (MCQ, Text, etc.).
QuestionNavigator: A virtualized list of jump-links to all questions in the exam, showing their visual states (Answered, Unanswered, Flagged).
SyncStatusBar: A persistent visual widget conveying remote API connectivity and synchronization queue status.
TelemetryTracker: Invisible global lifecycle interceptor listening for focus, blur, copy, paste, and resizing events.
SyncEngine: Background orchestrator coordinating IndexedDB writes, retries, and REST/GraphQL sync sweeps.

CUJ Walkthrough

Lobby & System Verification: The student logs in and lands on the SystemCheckPage. The browser requests webcam access, performs a dummy API ping to assess latency, and enforces fullscreen. Once passed, the student clicks "Start Exam".
Taking the Exam: ExamWorkspacePage mounts. The ExamStateMachine fetches and decrypts the exam metadata. The student sees the first question in the QuestionViewer and the full grid in the QuestionNavigator.
Answering & Offline Resilience: The student answers Question 1. QuestionViewer fires an answer event. The SyncEngine instantly updates the ExamStateMachine, saves the encrypted payload into IndexedDBStorage, and queues a debounced network write. If the network drops, SyncStatusBar shows "Offline - Saving Locally". The student continues answering questions smoothly.
Reconnection & Syncing: When connectivity is restored, the NetworkObserver signals the SyncEngine, which flushes the IndexedDB queue back to the APIClient. The UI transitions back to "All Changes Saved".
Submission: The student clicks "Submit". The system checks the offline queue. If any updates are pending, it forces a sync. Once the queue is clean, it issues a signed submission payload to the server and safely redirects to the confirmation page.

Simplicity Audit

This architecture is the simplest robust solution because it treats network connectivity as a volatile state rather than a constant. By storing all mutations locally first (IndexedDB as the single source of truth) and synchronizing with the API asynchronously, we eliminate complex UI state-reconciliation code, race conditions, and network-induced input stutters.

Architecture Decision Rationale

Why this architecture is the best for this problem?: High-stakes testing apps fail primarily due to client-side network interruptions and server overloading. Moving to an offline-first strategy decouples user actions from API responsiveness.
Requirement Satisfaction: Zero data loss is met by immediate IndexedDB persistence. Low-latency is achieved by running the active workspace in-memory using a unified local state. Security is handled via localized AES encryption and programmatic event interception.
---

System Diagram

---
Architecture Deep Dive

Presentation Layer

Component Hierarchy

The UI components are nested logically to isolate re-renders and preserve layout structures during state mutations:
AppShell: Outermost wrapper containing the router, global toast notices, and the main initialization logic.
ExamLayout: Structure-defining component containing the header band, the primary action footer, and the layout columns.
ExamWorkspacePage / SystemCheckPage: High-level routes. ExamWorkspacePage manages the state of the active question context.
Feature Containers:
QuestionViewer: Houses the dynamic question render block.
QuestionNavigator: Displays a high-performance grid of question buttons.
TelemetryTracker: Invisible context provider binding browser event interceptors.
Leaf Components: MCQOption, TextAnswerInput, NavigatorNode, and StatusIndicator are purely presentational and use rigid memoization.

Interaction Layer

Keyboard Navigation: Users can navigate back and forth using Alt + Left/Right or custom configurable shortcuts. MCQ choices are mapped to numeric hotkeys 1, 2, 3, 4.
Input Protection: Fullscreen is enforced on entry. Keydown interceptors block F11, Cmd+R, F12, Ctrl+C, and Ctrl+V. Focus/blur events capture if a student switches tabs, displaying a non-blocking modal warning.
Accessibility (a11y): Interactive elements have explicit tabindex. Active question states are announced using a dedicated ARIA live-region hook (aria-live="polite").
Responsive Layout: Designed primarily for desktop/tablet utilizing a CSS Grid split-pane layout. It is locked against ultra-narrow displays (<768px) to prevent structural breakdown.

Rendering Layer

Hybrid Rendering Strategy: Static SPA shell. The application wrapper is served as static HTML/CSS from a CDN, and the actual exam content is loaded on-demand on the client-side to ensure maximum resiliency against backend outages.
Virtualization: For long exams, QuestionNavigator uses virtual windowing (e.g., via lightweight virtual list patterns) to display thousands of items smoothly without bloating the DOM.
Reconciliation Strategy: Standard dynamic component maps render polymorphic inputs. To prevent heavy frame updates when switching questions, question items are cached in-memory and wrapped in custom memo components.

UI Frameworks / Tools

State-Aware UI Framework: React (or solid alternative) with fine-grained reactivity.
CSS Management: TailwindCSS for utility-first styling to ensure low runtime overhead and fast loading.
No External Heavy Component Libraries: Custom, highly accessible components built from scratch to prevent bundle bloat and maintain absolute control over keyboard layouts.
---

Application Layer

Data Fetching Layer

Staggered Pre-fetching: To avoid performance bottlenecks when 10,000 students join, the exam data fetch occurs during the SystemCheckPage phase via static chunk streams.
Parallel Client Cache: Answers are fetched on load and hydrated directly into IndexedDB. The application reads answers from IndexedDB and syncs to the server asynchronously.
Debounced Auto-save: Answer choices trigger a debounced save to the remote server (300ms delay) to prevent massive network floods when a user cycles rapidly through options.

State Management Layer

Global Exam State Machine: Powered by a lightweight state manager (e.g., Zustand or an XState machine). This strictly manages transitions:
\text{LOBBY} \rightarrow \text{SYSTEM\_CHECK} \rightarrow \text{EXAM\_ACTIVE} \rightarrow \text{SUBMITTING} \rightarrow \text{FINISHED}
Local Workspace State: The current answer state and the navigation pointer are kept in light, reactive local state variables.
IndexedDB Sync Core: Acting as the local-first source of truth. Every answered question executes a fast, synchronous write to IndexedDB, and subsequently fires a sync event to the application worker queue.

Routing & Navigation

SPARouting & Interceptors: Custom client-side router with route-guards.
Navigation Guards: Attempts to refresh, navigate away, or close the browser window trigger the browser's native beforeunload interceptor warning.
---

Domain Layer

                        +----------------------------+
                        |      Application Layer     |
                        |      (SyncEngine/Store)    |
                        +--------------+-------------+
                                       |
                   Commands / Queries  |   Invokes Interface
                                       v
                        +----------------------------+
                        |        Domain Layer        |
                        |  - Timer & Exam Rules      |
                        |  - Telemetry Evaluator     |
                        |  - Local Cryptography      |
                        +--------------+-------------+
                                       |
                   Implements Contract |   Dependency Inversion
                                       v
                        +----------------------------+
                        |     Infrastructure Layer   |
                        |  - IndexedDB  - APIClient  |
                        +----------------------------+

Business Rules / Use Cases

Immutable Timer Rules: Timer counts down in seconds. It runs in an isolated client-side worker thread to ensure browser UI thread execution delays do not slow down or artificially extend the exam time.
Telemetry Validator: Formulates client security evaluations, packaging security violations into an aggregated log payload before transmission.
Crypto Contract: Specifies interface methods for symmetric block encryption on strings (answers) and decryption on static data structures (questions).

Entities / Models

Question Schema: Structuring questions dynamically without structural mutations.
interface Question {
  id: string;
  type: 'MCQ' | 'TEXT';
  title: string;
  options?: string[];
}
AnswerState: Models client choices along with atomic timestamps.
interface AnswerState {
  questionId: string;
  selectedOptions: string[];
  textPayload?: string;
  updatedAt: number;
  synced: boolean;
}

Inter-layer Contracts

High decoupling using the Dependency Inversion Principle. The Domain Layer defines the interface for local state persistency (IStorageService) and network interactions (INetworkService). The Infrastructure Layer implements these protocols, ensuring the business domain has zero direct dependencies on external packages.
---

Infrastructure Layer

API / Network

Protocol: REST-like endpoints with compressed JSON payloads to ensure high operational efficiency.
Reliability Layer: Built-in HTTP retry mechanisms utilizing exponential backoff (e.g., 1s, 2s, 4s, 8s) combined with 25% randomized jitter to avoid concurrent retrying.
Request Deduplication: Uses dynamic hashing of answer mutations to merge overlapping queries, ensuring only the most up-to-date answer is dispatched over the network.

Storage

IndexedDB Engine: A fast, client-side relational storage module. It runs transactions on a dedicated target store (exam_answers_store).
Web Cryptography API Engine: An encryption/decryption middleware.
The local storage schema uses high-grade AES-GCM (256-bit) to encrypt keys.
The secret key is derived in memory on application mount and destroyed on unload to block DevTools extraction.
       [Student Action: Choice Made]
                    │
                    ▼
     [Store Local Copy in IndexedDB]
                    │
         (Async Background Workers)
                    │
                    ▼
        [Encrypt via Web Crypto API]
                    │
                    ▼
        [Push to SyncEngine Queue]
         ├── Network OK? ──> [Transmit Encrypted Data to API] ──> [Mark Synced]
         └── Network Down? ──> [Keep in IndexedDB] ──> [Retry When Online]
---
Wrap Up

Wrap-up

Evaluation & Trade-offs

Trade-off: Security vs. Client-side Overhead: Running client-side encryption (AES-GCM) on every keystroke/choice inside IndexedDB adds an processing overhead. Mitigation: The system utilizes web workers to hand off computational encryption tasks, maintaining 60 FPS on lower-tier client machinery.
Trade-off: Real-time Proctoring Latency: Constantly streaming high-fidelity audio/video requires enormous scale. Decision: To support 10,000 concurrent students cost-effectively, the platform defaults to decentralized local telemetry detection and random camera snaps instead of absolute live continuous streaming.

Advanced Optimization

Network Throttling Adaptability: If the NetworkObserver detects extremely low connection bandwidth, the SyncEngine scales down telemetry snapshot sizes, disables automatic asset pre-fetching, and pools text answers into compact, gzipped batches to preserve raw answer sync stability.
---