Design a banking system with payments and merging

## Design a banking system (progressive requirements) Design the backend for a simplified banking system that supports accounts, money movement, scheduled payments, cashback, ranking, and account merging. ### Core requirements 1. **Accounts & ledger** - Create accounts and store balances. - Record all transactions with an auditable history (do not lose history). 2. **Rank accounts by outgoing transactions** - Support querying a ranking/leaderboard of accounts based on **outgoing** transaction volume (e.g., total outgoing amount). - Clarify whether ranking is over *all time* or a *time window* (assume a configurable window such as last day/week/month). 3. **Scheduled payments with cashback + status tracking** - Users can schedule a payment to execute in the future. - Each scheduled payment has a **status** that can be queried. - Payments may provide **cashback** (e.g., a percentage of the outgoing amount) credited after the payment is executed. 4. **Merge two accounts** - Support merging two accounts while retaining **both balances** and **both transaction histories** for audit. - After merge, define how future transactions behave (assume: future activity goes to a “merged” view, while original accounts remain queryable/read-only for history). ### Non-functional requirements (state assumptions) - Correctness and consistency are critical (no double-spend). - Idempotency for payment execution. - Handle concurrent transfers and scheduled executions. - Scale to millions of accounts and high transaction throughput. ### What to produce - High-level architecture and key services. - Data model (tables/entities) and critical fields. - API sketches for: transfers, scheduled payments, status checks, ranking query, merge. - Consistency approach and failure handling (retries, idempotency, reconciliation). - How ranking and cashback are computed efficiently at scale.