Payment handling in LLD - System Design Exercise

Design: Payment Handling System

In scope: Payment processing, status tracking, refund handling, transaction storage. Out of scope: User authentication, merchant onboarding, fraud detection.

Functional Requirements

FR1: Accept payments from users via multiple methods (credit card, debit card, digital wallets).

FR2: Process payments securely and reliably.

FR3: Support refund and cancellation requests.

FR4: Provide real-time payment status updates to users.

FR5: Maintain transaction history for audit and reporting.

FR6: Handle at least 10,000 concurrent payment requests.

FR7: Ensure payment processing latency under 2 seconds for 99th percentile.

FR8: Ensure system availability of 99.9% uptime.

Non-Functional Requirements

NFR1: Sensitive data must be encrypted and comply with PCI DSS standards.

NFR2: System must be scalable to handle peak loads during sales or events.

NFR3: Latency for payment confirmation should be low to improve user experience.

NFR4: High availability to avoid payment downtime.

NFR5: Refunds must be processed reliably and idempotently.

Think Before You Design

Questions to Ask

❓ Question 1

❓ Question 2

❓ Question 3

❓ Question 4

❓ Question 5

❓ Question 6

Key Components

API Gateway for client requests

Payment Processor service

Third-party payment gateway integrations

Database for transaction records

Cache for quick status lookups

Message queue for asynchronous processing

Notification service for status updates

Design Patterns

Event-driven architecture for asynchronous payment processing

Circuit breaker pattern for third-party gateway failures

Idempotency keys to avoid duplicate payments

Retry mechanisms for transient failures

Database transactions for consistency

Reference Architecture

Client
  |
  v
API Gateway
  |
  v
Payment Processor Service <--> Payment Gateway(s)
  |
  v
Message Queue --> Refund Processor
  |
  v
Database (Transactions)
  |
  v
Cache (Payment Status)
  |
  v
Notification Service
  |
  v
Client

Components

API Gateway

RESTful API server

Receive payment requests and route them to the payment processor

Payment Processor Service

Microservice (e.g., Node.js, Python)

Validate requests, handle business logic, interact with payment gateways

Payment Gateway(s)

Third-party services (e.g., Stripe, PayPal)

Process actual payment transactions with banks and card networks

Message Queue

RabbitMQ or Kafka

Handle asynchronous tasks like refunds and retries

Refund Processor

Microservice

Process refund requests reliably and idempotently

Database

Relational DB (e.g., PostgreSQL)

Store transaction records, payment statuses, and audit logs

Cache

Redis

Store recent payment statuses for fast retrieval

Notification Service

Push/Email service

Send real-time payment status updates to users

Request Flow

1. Client sends payment request to API Gateway.

2. API Gateway forwards request to Payment Processor Service.

3. Payment Processor validates request and generates idempotency key.

4. Payment Processor calls third-party Payment Gateway API.

5. Payment Gateway processes payment and returns result.

6. Payment Processor updates transaction status in Database.

7. Payment status cached in Redis for quick access.

8. Notification Service sends status update to client.

9. For refunds, client requests refund via API Gateway.

10. Refund Processor consumes refund request from Message Queue.

11. Refund Processor calls Payment Gateway refund API.

12. Refund status updated in Database and client notified.

Database Schema

Entities: - Transaction: id (PK), user_id, amount, currency, payment_method, status, created_at, updated_at, idempotency_key - Refund: id (PK), transaction_id (FK), amount, status, created_at, updated_at - PaymentMethod: id (PK), type (card, wallet), details (encrypted), user_id Relationships: - One Transaction belongs to one User - One Refund belongs to one Transaction - One User can have multiple PaymentMethods

Scaling Discussion

Bottlenecks

Payment Processor service CPU and memory under high concurrent load.

Database write and read throughput for transaction records.

Third-party payment gateway rate limits and latency.

Message queue backlog during peak refund requests.

Cache invalidation and consistency under heavy updates.

Solutions

Scale Payment Processor horizontally with load balancer and stateless design.

Use database sharding or read replicas to distribute load.

Implement circuit breakers and fallback strategies for payment gateways.

Increase message queue partitions and consumers for parallel refund processing.

Use cache expiration policies and event-driven cache updates to maintain consistency.

Interview Tips

Time: Spend 10 minutes understanding requirements and clarifying scope, 20 minutes designing architecture and data flow, 10 minutes discussing scaling and trade-offs, 5 minutes summarizing.

Emphasize security and compliance with PCI DSS.

Explain asynchronous processing for refunds and retries.

Discuss idempotency to avoid duplicate payments.

Highlight how caching improves user experience with fast status updates.

Describe how to handle third-party failures gracefully.

Show understanding of scaling bottlenecks and mitigation strategies.