Payment integration architecture in HLD - System Design Exercise

Design: Payment Integration System

Design covers payment processing flow, integration with payment gateways, security, and scalability. Out of scope are user account management and order management systems.

Functional Requirements

FR1: Allow users to make payments using multiple payment methods (credit card, debit card, digital wallets).

FR2: Support secure storage and transmission of payment data.

FR3: Handle payment authorization, capture, and refunds.

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

FR5: Integrate with external payment gateways and banks.

FR6: Ensure compliance with PCI-DSS security standards.

FR7: Support at least 10,000 concurrent payment transactions.

FR8: Provide high availability with 99.9% uptime.

Non-Functional Requirements

NFR1: API response latency must be under 300ms for payment initiation.

NFR2: System must handle peak loads during sales events (up to 50,000 transactions per hour).

NFR3: Sensitive data must be encrypted both in transit and at rest.

NFR4: System must be scalable to add new payment methods easily.

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

Authentication and Authorization service

Payment Processing Service

Payment Gateway Integrations

Database for transaction records

Cache for quick status retrieval

Message Queue for asynchronous processing

Monitoring and Logging system

Security components (encryption, tokenization)

Design Patterns

Circuit Breaker pattern for external gateway calls

Event-driven architecture for asynchronous payment status updates

Retry and backoff strategies for failed transactions

Tokenization to avoid storing sensitive card data

Load balancing for scaling API endpoints

Reference Architecture

Client
  |
  v
API Gateway -- Auth Service
  |
  v
Payment Processing Service
  |          \
  |           -> Message Queue -> Async Workers -> Payment Gateway Integrations
  |
  v
Database <-> Cache
  |
  v
Monitoring & Logging

Components

API Gateway

Nginx or AWS API Gateway

Handles incoming client requests, routes to services, enforces rate limiting and security.

Authentication and Authorization Service

OAuth 2.0 / JWT

Verifies user identity and permissions before allowing payment operations.

Payment Processing Service

Java Spring Boot / Node.js

Core business logic for payment initiation, validation, and coordination.

Message Queue

RabbitMQ / AWS SQS

Decouples synchronous API calls from slower external payment gateway interactions.

Async Workers

Kubernetes pods running worker processes

Process payment gateway requests asynchronously, handle retries and failures.

Payment Gateway Integrations

REST/gRPC clients

Communicate with external payment providers for authorization, capture, refunds.

Database

PostgreSQL

Store transaction records, payment statuses, and audit logs.

Cache

Redis

Store recent payment statuses for fast retrieval.

Monitoring & Logging

Prometheus, Grafana, ELK Stack

Track system health, performance, and audit payment flows.

Security Components

TLS, HSM, Tokenization libraries

Encrypt data in transit and at rest, tokenize sensitive card data.

Request Flow

1. Client sends payment request to API Gateway.

2. API Gateway forwards request to Authentication Service for user validation.

3. Upon success, request goes to Payment Processing Service.

4. Payment Processing Service validates payment details and stores initial transaction record.

5. Payment request is placed on Message Queue for asynchronous processing.

6. Async Workers consume the queue, call external Payment Gateway APIs for authorization.

7. Payment Gateway responds with success or failure; Async Workers update transaction status in Database.

8. Cache is updated with latest payment status for quick client queries.

9. Client can poll or receive webhook notifications for payment status updates.

10. Monitoring system collects logs and metrics throughout the process.

Database Schema

Entities: - User (user_id, name, email) - Transaction (transaction_id, user_id, amount, currency, status, payment_method, created_at, updated_at) - PaymentMethod (payment_method_id, type, details_tokenized) - PaymentGatewayResponse (response_id, transaction_id, gateway_name, status, response_data, timestamp) Relationships: - User 1:N Transaction - Transaction 1:1 PaymentMethod - Transaction 1:N PaymentGatewayResponse

Scaling Discussion

Bottlenecks

API Gateway can become a bottleneck under high concurrent requests.

Database write and read load increases with transaction volume.

External payment gateway latency and rate limits can slow processing.

Message Queue saturation if async workers are slow.

Cache invalidation and consistency under heavy load.

Solutions

Use load balancers and auto-scaling groups for API Gateway and services.

Implement database sharding or read replicas to distribute load.

Use circuit breakers and fallback strategies for payment gateway calls.

Scale async workers horizontally and monitor queue length for auto-scaling.

Use cache with TTL and event-driven invalidation 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 security, 5 minutes summarizing.

Emphasize security and PCI-DSS compliance.

Explain asynchronous processing to handle slow external gateways.

Discuss how to handle failures and retries gracefully.

Highlight scalability strategies for peak loads.

Mention monitoring and alerting for operational health.