HireQuest runs timed, proctored assessments for graduate hiring. That creates a hard engineering problem: everyone starts at the same moment, everyone saves answers constantly, and losing a single answer is not acceptable.
Before opening it up to larger hiring rounds, we tested it the way exam day actually behaves.
The setup
- Production stack: PostgreSQL, Redis, S3 storage and 4 API replicas
- k6 scripts simulating candidates starting a test together and saving answers as they go
- Run in September 2026 in lab conditions on a single machine
Running everything on one machine is harsher than a real deployment, so treat the results as a lower bound for dedicated servers.
The results
- 1,000 concurrent candidates
- 84 ms p95 response time
- About 1,970 answers saved per second
- 1 errored request out of roughly 142,000
The failover drill
Throughput is only half the story. We also took components down in the middle of a run to see what candidates would lose. After the drill, there were 0 answers left pending: every answer a candidate submitted was saved.
That came from designing the save path so answers are acknowledged only once they're safely stored, and retried transparently if anything in between fails.
What we'd tell any team
- Test the busiest real moment, not an average day
- Measure the p95 or p99 latency, not the average
- Break things on purpose and check what users would lose
- Write down the conditions next to the numbers, so they stay honest
If you're building something that has to work on its busiest day, we'd be glad to talk it through.