## Prompt Design an internal ledger service that records immutable debit and credit entries, returns account balances, and scales to high write volume. The design must make retried write requests idempotent. Focus on ledger correctness and scalability rather than integration with an external payment processor. ### Constraints & Assumptions - Every accepted transaction balances: total debits equal total credits. - Posted ledger entries are immutable; corrections use compensating entries. - A client supplies an idempotency key scoped to its identity. - Balance reads may expose an `as_of` sequence so callers know their freshness. ### Clarifying Questions to Ask - Must transfers be strongly consistent across accounts in different shards? - What write throughput, hot-account behavior, and balance-read latency are expected? - Are pending and posted states both required? ```hint Bind the key to the request Store a canonical request hash with the idempotency result so reusing a key for different entries is rejected. ``` ```hint Rebuild balances from entries A balance table is a performance projection; immutable journal entries remain the basis for reconciliation. ``` ### What a Strong Answer Covers - Double-entry data model, transaction boundaries, and invariant enforcement. - Idempotency-key storage that returns the original result and detects conflicting retries. - Authoritative journal versus derived balance projections. - Partitioning, ordering, hot-key, replication, and recovery choices. - Reconciliation, audit, observability, and correction workflows. ### Follow-up Questions 1. How would you support a transaction that touches accounts on different shards? 2. How would you detect that a balance projection missed an entry? 3. What consistency should an API promise immediately after a successful write?