Medium · 13 steps · ~45 min

Design a document processing pipeline

Take invoices, contracts and forms in bursts, read them with OCR and a model, check the results and send doubtful ones to people.

Customers upload invoices, contracts and forms as PDFs and images. The system stores each file, runs OCR and layout parsing, asks a model to extract structured fields, validates them, sends low-confidence results to a human review queue and writes the rest to a database. Uploads arrive in bursts at month end, workers die, and the model provider has outages. The work is slow, expensive and full of personal data, so you must decide what is synchronous, what is queued, what you trust, and how long you keep anything.

Same problem as Invoice and form extractionContract review tools

How it works

• The customer is answered as soon as the file is stored and queued; everything after that runs asynchronously.
• Parsing and OCR fleets feed a model that returns fields with a confidence for each.
• Validation checks schemas and cross-checks and never trusts a total it can recompute; doubtful results go to a review queue.
• Every stage must be idempotent, because queues redeliver and clients retry.
• A GPU fallback keeps extraction alive when the hosted provider is down.

What you'll build

1. The document API and its data model
2. Upload, store, queue, parse and OCR
3. Model extraction, validation, review queue and results database
4. A design that absorbs the month-end burst
5. Survival of a lost OCR server and a provider outage

Steps

1. 1Design the document API
2. 2Design the data model
3. 3Take uploads and parse them
4. 4Extract fields with a model
5. 5Validate, review and store the results
6. 6Confidence thresholds and the human review rate
7. 7Validating model-extracted fields
8. 8Survive the month-end burst
9. 9Idempotent processing and duplicate uploads
10. 10Lose an OCR GPU mid-burst
11. 11Batch or real-time processing?
12. 12Survive a provider outage
13. 13PII handling and retention of uploaded documents