Amazon·Software Engineer·Onsite - System Design / Architecture·Intermediate

IntermediatePrefer not to say

Jun 2026

Summary

Amazon system design round for a software engineer role, one big OOP question that took the whole session. The question was meaty enough that I kept second-guessing whether I was going too deep on modeling or not deep enough on the operational logic.

Questions Asked (1)

Design a credit card system using object-oriented principles. Model the core entities (Cardholder, Card, Account, Transaction, Statement) and their relationships, and support operations like issuing cards, authorizing charges, recording payments, generating monthly statements, and tracking transaction history. Also discuss how you'd handle declined transactions and over-limit scenarios.

System DesignData ModelingTechnical Trade-offs

Author's notes

Started with the entities and drew out relationships pretty confidently, Cardholder owns an Account, Account has many Cards, Cards generate Transactions, Transactions roll up into Statements.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

Start by clarifying requirements and scope, then identify core entities and their relationships using OOP principles like encapsulation and inheritance. Walk through key operations (issuing cards, authorizing charges, recording payments, generating statements) and discuss how to handle declined transactions and over-limit scenarios with appropriate state management and business rules.

Pro tip: Emphasize immutability and auditability for financial transactions, and discuss how you'd model money using a dedicated Money class to avoid floating-point errors. Also, mention idempotency for payment operations to prevent duplicate charges.

1. Clarify Requirements and Scope

Ask clarifying questions about scale, concurrency, regulatory constraints, and specific features like credit limits, interest calculation, and statement cycles. Define the boundaries of the system.

2. Identify Core Entities and Relationships

Model Cardholder, Card, Account, Transaction, and Statement with appropriate attributes and methods. Define relationships: a Cardholder has Accounts, an Account has Cards and Transactions, and Statements are generated from Transactions.

3. Design Key Operations and State Management

Detail operations: issuing cards (create Card linked to Account), authorizing charges (validate against credit limit and account status), recording payments (update balance, ensure idempotency), generating statements (aggregate transactions over a period), and tracking history (query transactions).

4. Handle Edge Cases and Error Scenarios

Discuss declined transactions due to insufficient credit, expired card, or fraud suspicion. Explain over-limit handling: either decline or allow with fee, and how to update account state accordingly. Include concurrency control (e.g., locking) to prevent race conditions.

5. Discuss Trade-offs and Extensibility

Talk about design trade-offs: inheritance vs. composition for card types, synchronous vs. asynchronous authorization, and how to extend for new features like rewards or multiple currencies. Mention patterns like State or Strategy for transaction states.

Key Points to Mention

Encapsulation of business rules within entities (e.g., Account validates credit limit before authorizing a charge).
Use of a Money value object to handle currency and avoid floating-point precision issues.
Idempotency keys for payment and authorization operations to prevent duplicate processing.
State pattern to model transaction lifecycle (e.g., PENDING, APPROVED, DECLINED, SETTLED).
Concurrency control mechanisms (e.g., optimistic locking or database transactions) to handle simultaneous charges.
Auditability and immutability of transaction records for compliance and dispute resolution.

AI-generated suggestions, not part of the candidate's original notes. May be inaccurate — verify before relying on them.