Design a Monthly Account Statement Generation Batch

Design the system that generates monthly account statements for every customer of a digital bank. For each account it gathers the period's transactions, computes opening and closing balances and summaries, renders a PDF (and machine-readable copy), stores it durably, and notifies the customer that it is ready. Statements are legal financial documents, so a statement, once issued, must be exact, reproducible, and never silently changed.

Operating context. The batch runs on each account's statement cycle date; cycles are staggered across the month but a single day can still fall due for tens of millions of accounts. Input is the immutable ledger for the period. Rendering is CPU-heavy and storage is large. Assume 50 million accounts, a peak day of 5 million statements, and a requirement that every eligible account gets exactly one statement per cycle, on time.

Out of scope. The ledger's correctness, tax or regulatory report generation, the email/push delivery infrastructure beyond enqueuing a notification, and the in-app viewer. Assume separate teams own ledger, notifications, and the customer app.

What to produce. A high-level architecture covering: how the batch is triggered and how work is divided into parallel units, gathering the period's data as a stable snapshot, the render-and-store pipeline, guaranteeing exactly-one statement per account per cycle under retries and worker failure, idempotent regeneration when a bug is fixed, storage and retrieval at scale, and how you meet the deadline on a peak day. Sketch the stages and dataflow; we will probe specifics in checkpoints.