Katkat
Back

Design a banking system with payments and merging

RampSoftware Engineer · Online Assessment
MediumSoftware EngineerOnline AssessmentSystem Design

Last updated

This question tests your ability to design a robust, distributed financial ledger system that handles high-throughput transactions, ensures strict consistency, and supports the complex operation of merging two distinct user accounts.

System Design: Banking Ledger and Account Merging

Design a backend architecture for a corporate banking platform that handles account balances, money transfers, and a 'Merge Accounts' feature. The system must process high volumes of transactions while maintaining absolute data integrity.

Functional Requirements

  1. Transfer Service: Support transferring funds between two internal accounts.
  2. Account Merge: Allow a user to merge a 'Source' account into a 'Destination' account. All historical transactions must be moved to the destination, and the source account must be disabled.
  3. Transaction History: Retrieve a paginated history of transactions for a specific account ID.

Non-Functional Requirements

  • Consistency: Financial balances must be ACID compliant. No money should be created or lost.
  • Idempotency: Client-side retries for transfers must not result in duplicate transactions.
  • Auditability: Every state change must be immutably recorded for compliance.
  • Scale: Handle 5,000 transactions per second (TPS) globally.

Expectations

  • API Design: Define the necessary service endpoints.
  • Data Model: Propose a schema for Accounts and LedgerEntries.
  • Merging Logic: Explain how you handle a merge operation while concurrent transactions might be hitting the source account.
  • Scalability: Describe how you would shard the database (e.g., by UserID or AccountID) and handle distributed transactions.

Hints

Hint 1

Consider using a double-entry bookkeeping pattern where every transaction consists of two ledger entries (a debit and a credit) to ensure the total system balance is always zero.

Hint 2

For the merge operation, use a state-machine approach where the account enters a 'PENDING_MERGE' state to prevent incoming transactions before finalizing the transfer of history.

Hint 3

Use a unique `Idempotency-Key` provided by the client for every transaction, storing it in a key-value store with a TTL to prevent re-processing.

Follow-up questions

  • How would you handle a scenario where the merge process fails halfway through after some records have been moved?
  • If the system requires read-after-write consistency, how would you address the latency issues introduced by synchronous database replication?
  • How would you implement a 'soft-lock' or rate-limiting mechanism to prevent a single account from being flooded with concurrent transfer requests?