Design Credit-Card Authorization, Limit Decisions, and Reporting

Design a credit-card system supporting these capabilities: - Application login. - Payment authorization using fraud detection. - Monthly credit-bureau reporting. - A view of the user's spending status. - Real-time approval or denial of credit-limit increase requests. Start with the main entities, services, and read/write paths, then explain a focused design for payment idempotency. Discuss where a queue is useful and how you would choose between running application services on EC2 capacity or AWS Fargate. The exercise supplies no underwriting policy, fraud thresholds, bureau file format, or service-level targets. Treat those as contracts to obtain; do not invent actual issuer or regulatory rules. ### What a Strong Answer Covers - Clear ownership of identity, account/limit state, authorization decisions, ledger events, and report runs. - A synchronous decision path with atomic credit availability checks and repeat-request behavior. - Distinctions between pending authorizations, posted spending, and reporting snapshots. - A versioned and auditable limit-decision path that handles concurrent account changes. - Asynchronous work and compute choices justified by workload and operational requirements. ### Follow-up Questions - What happens if an authorization decision commits but its response is lost? - How would you rerun a monthly report or correct it without silently duplicating the original submission?