Design a CAPTCHA System

A CAPTCHA system has a deceptively simple surface: show a puzzle, check the answer, let humans through and block bots. The real engineering challenge is that every design decision sits on a tension line between security and usability. Make the challenge too hard and legitimate users abandon your form. Make it too easy and bots sail through. The system must find the right balance dynamically, adapting to evolving threats in real time.

Functional

Generate diverse challenge types: The system produces image-based challenges (select all traffic lights), distorted text challenges (type the characters you see), and audio challenges (listen and type the spoken word). Supporting multiple types matters because a bot trained to solve distorted text cannot solve image recognition puzzles, and vice versa. Variety is a security feature.

CAPTCHA traffic patterns are unusual: the system handles many short-lived interactions (generate challenge, validate response) rather than long-running sessions. The key insight is that challenge generation is the expensive operation, not validation. Pre-generating challenges transforms the capacity problem from real-time computation to storage and retrieval.

Traffic

10 million CAPTCHA interactions per day: This covers a mid-to-large platform with CAPTCHA on login, signup, and comment forms. Average throughput: 10M / 86,400 = roughly 115 requests per second.

The API surface is deliberately small: generate a challenge, validate a response, and optionally request an accessible alternative. Keeping the API minimal reduces the attack surface. Every endpoint a bot can call is an endpoint it can abuse.

Challenge Generation

1POST /v1/captcha/challenge
2Headers: X-Device-Fingerprint (optional), X-Session-ID
3Body: {
4  context: string (login, signup, comment),
5  preferred_type: string (image, text, audio) (optional)
6}
7Response: 200 OK {
8  challenge_id: string,
9  type: string,
10  media_url: string,
11  instructions: string,
12  expires_at: ISO-8601
13}

The data model reflects the system's dual nature: ephemeral challenge data that lives for minutes, and persistent interaction logs that live for months. Using the right storage technology for each workload is the key decision here.

Redis: Active Challenge Store

1Key: captcha:{challenge_id}
2Value: {
3  answer_hash: string,
4  type: string,
5  difficulty: number,
6  context: string,
7  session_id: string,
8  created_at: timestamp
9}
10TTL: 300 seconds (5 minutes)

The architecture separates challenge serving from challenge validation, and both from the risk assessment pipeline. This separation exists because each path has different performance characteristics: serving is latency-sensitive and cacheable, validation is consistency-critical and stateful, and risk assessment is computationally intensive but latency-tolerant.

Challenge Serving Path

Two primary flows define the system: the challenge flow (generating and serving a CAPTCHA) and the validation flow (checking the user's answer and issuing a token). Understanding the exact sequence at each step reveals why the architecture is structured the way it is.

Challenge Generation Flow

The core engineering challenge (the GATE of this problem) is building a risk-scoring pipeline that collects behavioral signals and computes a risk score before showing any challenge. This is what separates a modern CAPTCHA from a static puzzle: the system evaluates whether you are human before testing whether you are human, using the test only as confirmation when the signals are ambiguous.

Behavioral Signal Collection

Every decision in this system sits on the tension line between security and usability. Understanding these trade-offs demonstrates deliberate engineering judgment rather than pattern-following.

Harder Challenges vs. User Abandonment

Harder challenges (complex image grids, heavily distorted text) stop more bots. Modern ML models struggle with multi-step image selection (select all traffic lights across 9 cells, then 9 more cells). The cost: legitimate users take 15-20 seconds per challenge, and abandon rates increase by 10-15% per difficulty tier. For an e-commerce checkout, that abandonment directly translates to lost revenue.

The system's reliability comes from understanding how each component fails and ensuring no single failure compromises both security and availability simultaneously.

Challenge Generation Service Down

These improvements extend the system beyond basic challenge-response verification without changing the core architecture. Each builds on the existing risk scoring and analytics infrastructure.

Real-Time Difficulty Tuning

The current adaptive difficulty adjusts parameters based on aggregated metrics every 5 minutes. Real-time tuning would adjust per-request based on live solve rates and bot detection confidence. If the system detects a sudden spike in solve rates for a specific challenge type (indicating a new solving model in the wild), it shifts traffic to other types within seconds rather than waiting for the next aggregation cycle. This requires streaming analytics (Apache Flink) replacing batch aggregation, with sub-second feedback to the risk engine.