Design a real-time card-authorization service for Chime’s debit-card product that is tailored to the unique life-cycle of gas-station (“pay-at-pump”) purchases.
Functional requirements
When a member swipes at the pump, the service must authorize a hold amount (typically $75–$100) within 2 s (Visa/MasterCard network timeout). The member’s available balance must immediately decrease by the hold.
The member then pumps fuel; the final amount is unknown at auth time. Hours (or days) later the merchant sends a settlement/capture message for the actual amount (say $47.32). The service must match the settlement to the earlier auth, release any excess hold, and post the precise debit.
If the settlement never arrives (network loss, merchant batch drop), a nightly cron must auto-release the hold after 7 days for fuel (30 days for hotel/car-hold use cases).
The system must tolerate partial outages: approve or decline in <2 s without waiting on slow subsystems; deeper fraud scoring may run asynchronously.
Must support 5 k auth requests per second (peak) and 50 M cardholders; 99.99 % availability; multi-region active-active; exactly-once balance impact.
Non-functional requirements
PCI-DSS compliance: PAN must be tokenized outside the auth path; no sensitive data in logs.
Fraud detection: velocity limits, merchant block-list, and ML score must be evaluated inside the 2 s budget using pre-computed features cached in memory.
Audit: every auth and settlement must be immutable and queryable for 7 years.
Cost: use commodity infrastructure; no single-box appliances.
API contracts for auth request/response and settlement webhook.
Data model showing how an auth record can stay open for days and how settlement fuzzy-matches (issuer auth code, merchant ID, PAN, amount ± tolerance).
Brief capacity plan: QPS, storage growth, cache size, and how you shard the in-memory balance ledger to meet the 2 s SLA.