Katkat
Back

Design a High-Throughput Payment Authorization and Settlement System

OpenAISoftware Engineer · Onsite
HardSoftware EngineerOnsiteSystem Design

Last updated

This problem tests the ability to design a high-throughput, fault-tolerant distributed system that bridges external payment processors with internal ledger state management.

Problem Statement

Design a payment authorization and settlement system capable of processing 10,000 requests per second (RPS). The system acts as a middleware between end-user clients and external third-party payment gateways (e.g., Stripe, PayPal).

Functional Requirements

  1. Authorization: Request an auth token or capture from an external provider.
  2. Settlement: Asynchronously complete the transaction (capture funds) once authorization is successful.
  3. Idempotency: Ensure the same transaction is not processed twice despite network retries.
  4. Audit Trail: Maintain a record of all state transitions (PENDING, AUTHED, SETTLED, FAILED).

Non-Functional Requirements

  • Throughput: 10,000 RPS.
  • Consistency: Strong consistency required for ledger balances; eventual consistency is acceptable for UI status updates.
  • Availability: High availability; the system must handle transient failures of external providers.

Deliverables

  1. API Design: Define the primary request/response contracts.
  2. Data Model: Design the database schema for transactions and ledgers.
  3. Architecture: Describe the service components (e.g., Load Balancers, Queues, Database, Workers).
  4. Failure Strategy: How do you handle a scenario where an external gateway responds with a timeout after processing the charge on their end?

Constraints

  • Use a database that supports ACID transactions.
  • Assume external providers can be slow or unresponsive.

Hints

Hint 1

Consider using an idempotency key passed from the client to prevent double-charging during retry attempts.

Hint 2

Decouple the synchronous authorization flow from the asynchronous settlement flow using a message queue to manage spike traffic and provider latency.

Hint 3

Think about the 'Distributed Transaction' problem: if the database update fails after an external payment succeeds, how do you reconcile the state?

Follow-up questions

  • How would you implement a rate-limiting mechanism to ensure we don't overwhelm external providers during a spike in traffic?
  • If the database becomes the bottleneck at 10,000 RPS, what sharding strategies would you employ for the transaction table?
  • How would you design the system to handle 'webhooks' from external providers to update the transaction status asynchronously?