Design a reconciliation service that continuously compares the internal ledger against external sources of truth — bank statements, card-network settlement files, and processor reports — and surfaces every discrepancy for investigation. Its job is to answer one question with confidence: does what we think happened match what the outside world says happened, down to the last cent?

Operating context. Each day the service ingests millions of internal transactions plus dozens of external files that arrive on different schedules, in different formats, and often late or duplicated. It must match records across these sources, classify anything unmatched (missing, duplicate, amount mismatch, timing difference), and feed an operations queue. Assume roughly 20 million internal records and 15 million external records per day, growing, and a regulatory requirement to close each day's books within a fixed window.

Out of scope. The ledger's own correctness, the upstream payment authorization flow, the manual investigation UI beyond the queue it consumes, and automated remediation of breaks. Assume operations analysts resolve breaks by hand and separate teams own the source systems.

What to produce. A high-level architecture covering: ingestion and normalization of heterogeneous internal and external feeds, the matching engine and its keying/fuzzy strategy, how you handle late-arriving and duplicate files, the data model for matches and breaks, how a day is partitioned and closed, replay/backfill when a source is corrected, and scaling the match to tens of millions of records within the daily window. Sketch the pipeline stages and dataflow; we will probe specifics in checkpoints.