Design a Real-Time Document Processing & Extraction

Problem statement

Design a real-time document processing and extraction platform that ingests incoming documents (PDFs, JPEGs, PNGs, scanned TIFFs), runs OCR or native-text extraction, classifies the document type, parses business fields (invoice number, date, total amount, vendor name, line items), stores the structured results in a database and a search engine, and notifies the submitter within seconds-to-minutes. Documents that fall below a confidence threshold are routed to a human review queue before their results are published.

This is not a nightly batch OCR job. The brief is explicit: streaming ingestion, an event-driven extraction pipeline, asynchronous status updates, and real-time user feedback. The distinguishing engineering property is that each document is a self-contained unit of work with a heavy, variable compute cost (a 4-page scanned invoice takes 5-20 seconds of OCR; a native-text contract takes 200 milliseconds) and a light, fixed-shape result (roughly 4 KB of structured JSON). The architecture must absorb bursts, isolate slow documents, guarantee that no document is lost or processed twice, and make the confidence of every extracted field visible downstream.

Why the problem is distinctive

A log pipeline processes uniform records. A document pipeline processes heterogeneous artifacts: a crisp native-text PDF, a 300dpi fax of a crumpled receipt, a 60-page contract with nested tables. Three consequences follow. First, compute cost per item varies by two orders of magnitude, so the pipeline needs adaptive routing (text layer first, OCR only when needed) and isolation between cheap and expensive work. Second, correctness is probabilistic: every extracted field carries a confidence score, and the system must decide per-field whether to auto-publish, escalate to human review, or reject. Third, documents are legally sensitive artifacts — invoices and contracts carry PII and financial obligations — so retention, encryption, and audit are architecture requirements, not afterthoughts.

Real-world operating baseline

The category is operationally mature. ABBYY reports processing more than 4 billion pages per year through its IDP platform. DocAI states its platform handles more than 1 million documents per week across customers, with per-model throughput in the hundreds-to-thousands of pages per minute range. AWS Textract documents synchronous single-page APIs plus asynchronous multi-page jobs, and its default quotas start around 1 transaction per second for synchronous calls, scaling on request — which is exactly why production designs pair a queue with autoscaling workers rather than calling the API inline from a web request. UiPath Document Understanding ships template-less extraction with a human-in-the-loop validation station as a first-class product surface. These are cited public figures for context; every capacity number used later in this answer for our fictional system is an explicit design assumption.

The five architectural planes

1. Ingestion plane: authenticated upload, format validation, virus scan, content-addressed storage, durable job emission.
2. Processing plane: preprocessing, OCR/text extraction, layout analysis, classification, field parsing — orchestrated as a DAG of stages with retry and fallback.
3. Data plane: document metadata (strong), extraction results (transactional per document), raw files (immutable object storage), search index (eventual), analytics (eventual).
4. Human-review plane: confidence-based routing, reviewer workbench, corrections, and active-learning feedback.
5. Delivery plane: webhooks, polling APIs, search, and downstream analytics publication.

A strong interview answer keeps these planes separate. A reviewer correcting one field must not rewrite the raw document. A search-index outage must not block extraction. A burst of 60-page contracts must not starve one-page receipts.