Generate and Reuse Invoices on Demand for a Customer and Time Range

Design an invoice service. One invoice contains multiple transactions. The requested time range is supplied only when the client calls the logical `getInvoice` operation; the service must generate the invoice on demand and store it for repeated requests with the same customer and time range. Cover the API model, reliability, security, database choices, and when the downloadable invoice becomes available. ### Constraints & Assumptions - Do not replace on-demand generation with a precomputed invoice for every possible range. - Identical customer/range requests should reuse the stored result or in-progress generation. - Clarify range boundaries, time zones, transaction eligibility, and whether later corrections require an explicit invoice revision. - The logical operation name does not prescribe an HTTP method or synchronous implementation. ### Clarifying Questions to Ask - Must the first request wait for generation, or may it return a pending resource? - Should a generated invoice preserve a transaction snapshot even if source records later change? - Who may request and download invoices for a customer? ### Part 1 — Request, Generate, and Reuse Define the canonical request identity and the flow from a new range request to a ready file. #### What This Part Should Cover - Customer/range normalization and a uniqueness constraint. - One generation job for concurrent duplicate requests. - Transaction selection, consistent content, and stored artifact identity. ### Part 2 — Reliability and Secure Availability Explain failures, downloads, and data-store choices. #### What This Part Should Cover - Pending, ready, and failed states with retry-safe generation. - Metadata and transaction storage versus document-object storage. - Authorization on every access and an honest readiness contract. ```hint The file is not ready merely because a job exists. Trace the point when a complete object and its authoritative metadata are both available. ``` ### What a Strong Answer Covers The service should produce one reusable invoice for the requested customer/range identity, survive duplicate requests and worker failures, and expose the downloadable artifact only when complete and authorized. Explain how revisions differ from accidental regeneration. ### Follow-up Questions - What happens if two clients request the same range simultaneously? - What if upload succeeds but the worker crashes before marking the invoice ready? - How would a transaction correction affect an already generated invoice?