Design a bank with scheduled payments and merges
Overview
This question evaluates data-structure and algorithm design competencies with emphasis on concurrency, time-based scheduling, aggregation (TopK), transactional consistency, idempotency, and merge semantics for an in-memory banking service, falling under the Coding & Algorithms and system-design domain.
HubSpot
Sep 6, 2025, 12:00 AM
Software Engineer
Take-home Project
Coding & Algorithms
0
0
Design an in-memory banking service that supports the following operations: (
- CreateAccount(accountId), (
- Deposit(accountId, amount), (
- Transfer(srcId, dstId, amount), (
- TopKByTotalOut(k) to return the k accounts with the largest cumulative outgoing amounts, (
- SchedulePayment(srcId, dstId, amount, executeAtEpochMillis) where a scheduled payment executes when its due time arrives and is skipped (not retried) if the source balance is insufficient, and (
- MergeAccounts(aId, bId) to combine two accounts into one (define the resulting accountId, combined balance, combined outgoing totals, and how to handle any scheduled-but-not-yet-executed payments for both accounts). Specify the data structures you would use to support efficient real-time updates and time-based execution (e.g., for scheduling), and describe how you would maintain the TopK view as deposits, transfers, merges, and scheduled payment executions occur. Provide clear method signatures, expected time and space complexities for each operation, and the rules for consistency and idempotency (e.g., handling duplicate requests or retries). Explain how you would process due payments continuously (or on a timer) and ensure correctness when multiple operations happen near the execution time. Discuss edge cases such as merging accounts that have pending scheduled payments, transferring to the same account, zero/negative amounts, and ties in TopK ordering.