# Design a Ledger Recording and Query System Design the ledger subsystem for a payment platform. Credit-card charging, fraud checks, and the API gateway already exist and are outside scope. Focus only on how accepted financial activity is recorded and queried with clear correctness, auditability, and failure behavior. ### Constraints & Assumptions - The upstream systems provide authenticated requests or events through an existing boundary. - Ledger history must not be silently rewritten after it has been accepted. - The accounting model, query set, scale, and consistency requirements must be clarified rather than inferred. ### Clarifying Questions to Ask - Is this a double-entry ledger, and which invariants must hold for every transaction? - Which queries are required: transaction history, account balance, point-in-time balance, or reconciliation exports? - Can an upstream request be delivered more than once, and how quickly must writes and queries become visible? ```hint Start with invariants Define what one accepted ledger write must preserve before choosing storage, partitioning, or read models. ``` ### What a Strong Answer Covers - Ledger transaction boundaries, immutable entries, idempotency, and corrections. - A strongly consistent source of truth plus query paths with stated freshness. - Atomicity, concurrency, retries, reconciliation, and audit evidence. - Partitioning, indexing, retention, access control, observability, and recovery. ### Follow-up Questions 1. How would you compute a point-in-time balance without scanning an account's entire history? 2. How would you detect and repair a derived balance that disagrees with authoritative entries?