Payment System — Naive (Single Service + SQL Transactions)

Designing a payment processing system is one of the most critical system design interview questions because it forces candidates to reason about financial correctness, idempotency, and the fundamental trade-off between synchronous simplicity and asynchronous throughput. The naive approach is where every candidate should start — it establishes the baseline that makes the improvements in the saga and distributed variants measurable and concrete.

The core challenge is processing a payment charge: receive a request from a merchant, authorize the charge with the card network (Visa, Mastercard, Amex), record the result in a database, and return the outcome. In the naive approach, this entire flow is synchronous. When a charge request arrives, PaymentService calls the card network directly — an external HTTP call that takes 200-500ms — then writes the result to PostgreSQL in a single SQL transaction. The merchant receives the final result (succeeded or failed) in the HTTP response. No pending state, no async processing, no webhooks.

The synchronous card network call is the fatal bottleneck. Each request thread is blocked for 200-500ms waiting for the card network response. With 3 pods running 50 threads each (150 threads total), maximum throughput is approximately 150 threads divided by 300ms average latency, which equals roughly 500 requests per second. During Black Friday traffic spikes, this ceiling is hit within minutes. Thread pool exhaustion causes charge requests to queue, latency spikes to seconds, and merchants experience timeouts that trigger retries — which brings us to the second critical flaw.

Without idempotency keys, network timeouts between the merchant and the payment API cause duplicate charges. If the first charge request succeeded but the HTTP response was lost due to a network timeout, the merchant retries with an identical request. The naive system processes it as a new charge, creating a second charge for the same purchase. At a 0.1% timeout rate and 500 RPS, that is one double charge every two seconds — a catastrophic failure mode for a payment system where every cent must be accounted for exactly once.

The absence of fraud detection is equally dangerous. A production payment system blocks 2-5% of charges as fraudulent using velocity checks (too many charges per card per minute), geo anomaly detection (card used in two countries within an hour), and ML-based risk scoring. The naive approach accepts every charge indiscriminately, making it vulnerable to card-testing attacks where fraudsters systematically test thousands of stolen card numbers against the API. At $50 average charge, undetected fraud at scale costs millions per day.

This template makes these failure modes visible and quantifiable. Run the simulation at 1,000 RPS and watch thread pool utilization spike to 100% while charge latency climbs past 3 seconds. The comparison with the Saga variant — where async Kafka processing drops charge latency to 50ms and idempotency keys eliminate double charges — provides the concrete evidence for why production payment systems never use synchronous card network calls.

The naive payment system is a four-component linear architecture: MerchantClient, Load Balancer, PaymentService, and PaymentDB (PostgreSQL). There is no API Gateway, no cache, no message queue, no fraud service, and no separation between the charge processing and card network interaction.

All traffic enters through the Load Balancer (AWS ALB), which distributes requests across PaymentService pods using round-robin. The LB adds approximately 1.5ms of routing latency and supports up to 5,000 RPS — well above the system's actual ceiling of approximately 450 RPS imposed by the synchronous card network bottleneck. The LB is not the constraint; the card network call is.

PaymentService is a stateless REST API running on 3 pods with 50 threads each (150 threads total). It handles four operations: (1) charge — receive the request, call the card network synchronously (200-500ms), write the result to PaymentDB, return; (2) refund — look up the original charge, call the card network to reverse it (another 200-500ms blocking call), write the refund record; (3) status check — read from PaymentDB; (4) reporting — SQL GROUP BY queries against PaymentDB. The charge and refund paths are dominated by the synchronous card network call. Status checks and reports compete with charge writes for the same database connection pool.

PaymentDB is a single PostgreSQL primary with no read replicas and no sharding. It stores three tables: payments (charge records with payment_id, amount, status, card_network), refunds (reversal records linked to original payments), and audit_log (append-only event history). The connection pool (200 connections) is shared between charge writes and status reads. At peak load, charge writes consume the majority of connections, causing status checks and reports to queue. There is no partitioning — a single B-tree index on payment_id handles all lookups.

The system has zero redundancy at the data layer. If the PostgreSQL primary fails, both charges and status checks are unavailable. There is no cache to serve stale reads, no read replica for reporting queries, and no multi-AZ deployment for database failover. The entire system is a single-region, single-AZ deployment where any component failure causes total downtime.

The concrete scaling ceiling is approximately 450 concurrent charge requests per second. At 300ms average card network latency, each thread handles roughly 3 charges per second. With 150 threads (3 pods times 50 threads), maximum throughput is 450 RPS. Beyond this, the thread pool is exhausted, requests queue in the LB, and charge latency climbs from 350ms to multiple seconds. At 1,000 RPS, the system is fully saturated with a growing queue that eventually causes LB connection timeouts.