Way To Serve Test Answers

Serving Test Answers Isn't As Simple As Dropping a File

Most people think this is about putting a document somewhere and waiting for clicks. I spent three weeks debugging why my grading script kept returning stale results, and it turned out the browser cache was holding onto answer keys from a quarter ago. The real issue wasn't the file path, it was the cache headers on the response. I ended up adding Cache-Control: no-store to the test server middleware and the problem went away overnight. I am going to walk through how I set this up for a university course with about 400 students taking three different exams simultaneously. The whole flow runs on a lightweight Node service, but the principles apply whether you are using PHP, Python, or a static CDN.

Way To Serve Test Answers

Start by deciding where the answers live. I keep them in a simple JSON file grouped by exam code and question index. The file looks like this: {"CS101": {"q1": "B", "q2": "A", "q3": "C"}} That structure lets me look up answers in O(1) time instead of parsing a CSV on every request. A CSV approach saved me about twenty minutes of setup but cost me roughly three hundred milliseconds per page load when 400 students hit the server at once. That added up fast during peak grading windows.

The next layer is the HTTP handler. I wrote a tiny Express route that takes two query params: exam and student_id. The student_id is required because serving the same answer key to everyone breaks academic integrity policies. I cross-reference the ID against a student roster stored in a SQLite database, which keeps the lookup under 5ms even with thousands of rows. One edge case caught me off guard. When students took the exam on tablets, their user agents reported as Mobile Safari/604 instead of the normal Chrome string. My original routing logic checked for chrome in the user agent to decide between mobile and desktop answer formats. Tablets failed that check and got routed to the desktop JSON endpoint, which returned answer bundles missing the mobile-specific formatting tokens. The fix was checking for iPad or iPod separately and treating them as mobile clients. Here is the actual response structure I send back:

{"status": "ok", "answers": ["B", "A", "C"], "checksum": "a3f2b1"} The checksum is an MD5 hash of the answer array. It lets the client verify the bundle wasn't tampered with between the server and the browser. I do not sign the response with a private key, that level of security is overkill for a practice exam. If you are handling high-stakes certification exams, you should be using JWTs with RS256 signatures instead. File permissions matter more than most guides mention. I set the answer JSON file to 600 and the server process runs under a dedicated service account, not root. This prevents other system users from reading exam content. On a shared hosting environment this is harder to enforce, and I have seen multiple cases where developers left answer files at 644 and accidentally exposed them to the public filesystem.

Rate limiting is non-negotiable. I use a sliding window counter stored in Redis that allows 10 requests per minute per IP. Without this, a single student could script the endpoint and scrape all answers in under a minute. The Redis instance adds about 2ms of latency per request, but that is far cheaper than an academic integrity investigation. The grading client sends back a POST to /grade with the student responses. I compare those against the answer key, calculate a score, and store the result in the database. The comparison function runs in O(n) where n is the number of questions. For a 100-question exam this takes roughly 0.3ms on a standard laptop CPU. One thing nobody warns you about: timezone mismatches. The server I deployed initially ran on UTC, but the exam system stored timestamps in America/New_York. This caused the exam window to appear open four hours longer than intended for students on the East Coast. The fix was storing all exam start/end times in UTC and converting to the student's local timezone only in the frontend. The backend should never make timezone decisions, it should just pass raw Unix timestamps.

If you are serving sensitive exam content, consider adding basic TLS termination. I use nginx as a reverse proxy in front of the Node service, which handles certificate renewal through Let's Encrypt. The Node app itself does not need to know about HTTPS. This setup adds roughly 5ms of latency for the TLS handshake on first connection, but subsequent requests reuse the session and add negligible overhead. The whole system, from question payload to scored result, completes in under 200ms for a 100-question exam on a $5/month VPS. That is plenty fast for most academic use cases. If you need sub-50ms response times across thousands of concurrent students, you will need to move the answer lookups into an in-memory cache like Memcached and optimize the JSON serialization path. I have found that the biggest performance bottleneck is usually not the server code but the network round trip between the student device and the grading API. Using HTTP/2 with multiplexing cuts the effective latency by about 30% compared to HTTP/1.1 when students load the exam interface and submit answers simultaneously. This is free if your hosting provider supports it.