Design Installment-Loan Payment Processing
Design a system to process payments for an active installment loan for an existing user. Payments can be initiated manually via an app or website, or automatically via a schedule. The system must debit the user's bank account. A critical constraint is that the bank debit API is synchronous but only available during a single, fixed one-hour window each day. After each debit attempt (successful or failed), the user must be notified via SMS or email.
Your design should cover APIs, state management, scheduling, bank interaction, retry mechanisms, accounting, and notifications.
Constraints & Assumptions:
- User and loan services are pre-existing and can be treated as stubbed APIs.
- The bank debit API returns a synchronous result only when its daily one-hour window is open; it is unavailable outside this window.
- Clients, schedulers, and worker processes may retry requests.
- A payment must never be debited twice due to a retry.
- Payment state and the loan's applied repayments must be reconcilable.
AI interview prep
Core dilemma
Balancing the strict, time-bound availability of the bank debit API with the need for reliable, exactly-once business effect processing and user notification, while handling potential failures and retries.
3 tradeoffs and 3 stress tests locked
Interview prep
Unlock the interviewer X-Ray rubric, tradeoff matrix, stress tests, clarifying questions, and key concepts.
Design Installment-Loan Payment Processing
Design a system to process payments for an active installment loan for an existing user. Payments can be initiated manually via an app or website, or automatically via a schedule. The system must debit the user's bank account. A critical constraint is that the bank debit API is synchronous but only available during a single, fixed one-hour window each day. After each debit attempt (successful or failed), the user must be notified via SMS or email.
Your design should cover APIs, state management, scheduling, bank interaction, retry mechanisms, accounting, and notifications.
Constraints & Assumptions:
- User and loan services are pre-existing and can be treated as stubbed APIs.
- The bank debit API returns a synchronous result only when its daily one-hour window is open; it is unavailable outside this window.
- Clients, schedulers, and worker processes may retry requests.
- A payment must never be debited twice due to a retry.
- Payment state and the loan's applied repayments must be reconcilable.