System Design #14 Hello Interview Stripe Guide Peak Load: 10,000 TPS

Design a Payment System (Stripe)

Financial-grade payment architecture: Client-side iFrame encryption (Zero-PCI footprint), PaymentIntent lifecycle, Operational DB with WAL-based CDC, Kafka Event Stream, Automated Reconciliation for network timeouts, and signed Webhooks.

Target: 100% Financial Auditability & Zero Data Loss

Peak Throughput10,000 TPSSharded by merchant_id

Card Data SecurityiFrame + HSMSAQ A (Zero merchant PAN)

Operational DB Latency< 8ms P99Write-Ahead Log (WAL) enabled

CDC Event Stream< 15ms DeltaKafka 3x Multi-AZ + S3 Archive

Network ReconciliationZero DriftAuto Timeouts & Batch Files

Simulate Flows:

Synchronous API Flow Encrypted Card Direct Route CDC WAL & Kafka Event Stream Signed Webhooks Delivery

Click any component box to view Hello Interview deep dive

Core Requirements (Hello Interview)

Functional 1: Merchants initiate payment requests (POST /payment-intents) with amount & currency.

Functional 2: Users pay with credit/debit cards via isolated iFrame SDK with client encryption.

Functional 3: Merchants receive real-time status updates via polling & signed Webhooks.

Non-Functional: High security (HMAC + HSM), zero lost data (CDC + Kafka + S3), async timeout safety (Reconciliation), and 10,000+ TPS scalability.

What is Expected at Each Level?

Mid-Level: Establish core payment flow, understand sensitive card details must not touch merchant servers, handle basic status updates and reasonable timeout handling.

Senior: Proactively articulate iFrame isolation, identify that external network timeouts require idempotent resolution rather than naive failure, and scale DB via merchant_id sharding.

Staff+: Champion event-driven CDC + Kafka architecture, defense-in-depth with HSM enclaves and HMAC request signing, and design resilient batch reconciliation for 100% financial integrity.

Merchant Server

Role & Overview

The merchant's backend application. When a customer reaches checkout, the merchant initiates a payment request to create a PaymentIntent. The merchant never sees or handles sensitive customer card details.

Architecture Implementation

Stores merchant public API key and private secret key securely in environment secrets. Generates HMAC-SHA256 signatures with timestamp and nonce for every API call.

Merchant Authentication & Request Signing

⚠️ Good Solution: Basic API Key Authentication (Bearer pk_live_...). Simple, but vulnerable to request tampering and replay attacks if intercepted.

⭐ Great Solution: Enhanced API Key + Request Signing (HMAC SHA-256). Generates signature over HTTP Method + Path + Body + Timestamp + Nonce using merchant secret. API Gateway recalculates HMAC, rejects requests with timestamp drift > 5 min, and verifies nonce is unused.

Specification & Snippet

// Merchant Request Signing Example
const timestamp = new Date().toISOString();
const nonce = crypto.randomUUID();
const payload = JSON.stringify({ amountInCents: 2499, currency: 'usd' });
const signature = crypto.createHmac('sha256', merchantSecret)
  .update(`POST|/payment-intents|${timestamp}|${nonce}|${payload}`)
  .digest('hex');

fetch('https://api.payments.com/payment-intents', {
  method: 'POST',
  headers: {
    'Authorization': 'Bearer ' + publicKey,
    'X-Request-Timestamp': timestamp,
    'X-Request-Nonce': nonce,
    'X-Signature': 'sha256=' + signature,
    'Content-Type': 'application/json'
  },
  body: payload
});