Payment handling in LLD - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ Architecture

intermediate

Designing a scalable payment processing system

You need to design a payment processing system that can handle thousands of transactions per second. Which architectural component is essential to ensure the system can scale horizontally and handle failures gracefully?

A A centralized monolithic server that processes all payments synchronously

B A distributed message queue to decouple payment requests from processing services

C A single database that stores all payment transactions and processes them sequentially

D A client-side script that processes payments directly without server interaction

💡 Hint

Think about how to handle high volume and failures without blocking the entire system.

Using a distributed message queue allows the system to handle many payment requests asynchronously. It decouples the request from processing, enabling horizontal scaling and better fault tolerance.

❓ scaling

intermediate

Estimating capacity for peak payment loads

Your payment system expects a peak load of 10,000 transactions per minute. Each transaction takes 200ms to process on average. How many concurrent processing workers do you need to handle the peak load without delay?

A 33 workers

B 200 workers

C 100 workers

D 50 workers

💡 Hint

Calculate how many transactions can be processed per second by one worker, then divide total transactions per second by that number.

10,000 transactions per minute equals about 167 transactions per second. Each worker processes 1 transaction in 0.2 seconds, so 5 transactions per second per worker. 167 / 5 = 33.4, so at least 34 workers are needed. To handle overhead and avoid delays, 50 workers is a safe estimate.

❓ tradeoff

advanced

Choosing between synchronous and asynchronous payment confirmation

In a payment system, you can confirm payments synchronously (immediate response) or asynchronously (delayed confirmation). Which tradeoff is true when choosing asynchronous confirmation?

A Asynchronous confirmation increases system scalability but may delay user notification of payment status

B Asynchronous confirmation improves user experience by providing instant success feedback

C Asynchronous confirmation reduces system complexity by avoiding retries and error handling

D Asynchronous confirmation guarantees immediate consistency of payment status across all services

💡 Hint

Think about how asynchronous processing affects user feedback and system load.

Asynchronous confirmation allows the system to handle more requests by processing payments in the background, improving scalability. However, it delays notifying the user about the payment result, which may affect user experience.

❓ component

advanced

Critical components for secure payment handling

Which component is essential to ensure secure handling of sensitive payment data in a payment system?

A A caching layer that stores payment data in plain text for faster access

B A load balancer that distributes payment requests without inspecting data

C An encryption module that encrypts payment data both at rest and in transit

D A logging system that records all payment data including card numbers for audit

💡 Hint

Consider how to protect sensitive data from unauthorized access.

Encrypting payment data at rest and in transit protects it from theft or leaks. Caching in plain text or logging sensitive data violates security best practices. Load balancers do not secure data themselves.

🧠 Conceptual

expert

Ensuring idempotency in payment processing

Why is idempotency critical in payment processing systems, and how is it typically implemented?

A Idempotency prevents duplicate charges by ensuring repeated requests with the same idempotency key are processed only once

B Idempotency allows multiple payments to be processed simultaneously without coordination

C Idempotency improves system speed by caching payment results indefinitely

D Idempotency is used to encrypt payment data before sending it to external services

💡 Hint

Think about what happens if a payment request is sent twice due to network issues.

Idempotency ensures that if the same payment request is received multiple times, only one payment is processed, preventing duplicate charges. This is usually done by assigning a unique idempotency key to each request and checking it before processing.

Practice

1. What is the primary purpose of a payment handling system in software design?

easy

A. To store user profile pictures

B. To securely process and record financial transactions

C. To manage user login and authentication

D. To display product information to users

Solution

1. Step 1: Understand the role of payment handling

   Payment handling systems focus on managing money transfers safely and reliably.

2. Step 2: Identify the core function

   The core function is to process payments securely and keep records of transactions.

3. Final Answer:

   To securely process and record financial transactions -> Option B

4. Quick Check:

   Payment handling = Secure transaction processing [OK]

Hint: Payment handling means safe money transfer and record keeping [OK]

Common Mistakes:

• Confusing payment handling with user authentication
• Thinking it manages product display
• Assuming it stores user media files

2. Which of the following is the correct sequence of steps in a typical payment processing flow?

easy

A. Notify user -> Record transaction -> Process payment -> Validate payment details

B. Record transaction -> Validate payment details -> Notify user -> Process payment

C. Validate payment details -> Process payment -> Record transaction -> Notify user

D. Process payment -> Notify user -> Validate payment details -> Record transaction

Solution

1. Step 1: Identify logical payment flow order

   First, payment details must be validated to ensure correctness.

2. Step 2: Follow with processing, recording, and notifying

   After validation, payment is processed, transaction recorded, then user notified.

3. Final Answer:

   Validate payment details -> Process payment -> Record transaction -> Notify user -> Option C

4. Quick Check:

   Payment flow = Validate -> Process -> Record -> Notify [OK]

Hint: Payment flows from validation to processing, then record and notify [OK]

Common Mistakes:

• Not validating before processing
• Not recording transaction before notifying
• Mixing notification before processing

3. Consider this simplified payment processing pseudocode:

def process_payment(amount, card_info):
    if not validate_card(card_info):
        return "Invalid card"
    if amount <= 0:
        return "Invalid amount"
    if not charge_card(card_info, amount):
        return "Charge failed"
    record_transaction(card_info, amount)
    return "Payment successful"

What will be the output of process_payment(100, 'expired_card') if validate_card returns False for expired cards?

medium

A. "Invalid card"

B. "Charge failed"

C. "Payment successful"

D. "Invalid amount"

Solution

1. Step 1: Check card validation result

   Since validate_card returns False for expired cards, the first if condition triggers.

2. Step 2: Return error message immediately

   The function returns "Invalid card" without further processing.

3. Final Answer:

   "Invalid card" -> Option A

4. Quick Check:

   Expired card -> validate_card = False -> "Invalid card" [OK]

Hint: If validation fails, function returns error immediately [OK]

Common Mistakes:

• Assuming charge_card runs despite invalid card
• Confusing invalid amount with invalid card
• Expecting success despite validation failure

4. A payment system logs duplicate transactions when retrying failed payments. Which design fix will best prevent this issue?

medium

A. Use unique transaction IDs and check before recording

B. Increase payment timeout duration

C. Remove transaction logging entirely

D. Allow multiple retries without checks

Solution

1. Step 1: Identify cause of duplicate logs

   Retries cause repeated transaction records without uniqueness checks.

2. Step 2: Implement unique transaction IDs and check

   Assign unique IDs and verify before logging to avoid duplicates.

3. Final Answer:

   Use unique transaction IDs and check before recording -> Option A

4. Quick Check:

   Unique IDs prevent duplicate transaction logs [OK]

Hint: Unique IDs stop duplicate transaction records [OK]

Common Mistakes:

• Ignoring duplicate checks on retries
• Removing logging which loses audit trail
• Increasing timeout doesn't fix duplicates

5. You are designing a payment system that must handle 10,000 transactions per second with minimal latency and high reliability. Which architectural approach best supports this requirement?

hard

A. Store all payment requests in a single database table and process sequentially

B. Process all payments synchronously on a single server to ensure order

C. Use client-side scripts to process payments directly without server validation

D. Use a distributed message queue to process payments asynchronously with multiple worker nodes

Solution

1. Step 1: Analyze scalability and latency needs

   Handling 10,000 TPS requires distributing load and minimizing blocking.

2. Step 2: Choose asynchronous distributed processing

   Using a message queue with multiple workers allows parallel processing and reliability.

3. Step 3: Eliminate options causing bottlenecks or insecurity

   Single server or sequential DB processing causes bottlenecks; client-side processing lacks security.

4. Final Answer:

   Use a distributed message queue to process payments asynchronously with multiple worker nodes -> Option D

5. Quick Check:

   High TPS + low latency = distributed async processing [OK]

Hint: Distribute load with async workers for high TPS [OK]

Common Mistakes:

• Using single server causing bottlenecks
• Sequential DB processing slowing throughput
• Relying on client-side payment processing