Katkat
Back

Design a Visa-like payment processing system

DatabricksSoftware Engineer · Technical Screen
HardSoftware EngineerTechnical ScreenSystem Design

Last updated

This problem tests your ability to design a high-throughput, fault-tolerant transaction processing system that guarantees data integrity across distributed services.

Design a Payment Processing System

Design the backend infrastructure for a global payment processing network (similar to Visa or Mastercard) that acts as an intermediary between merchants and issuing banks.

Functional Requirements

  1. Authorization: Verify cardholder balance/limit with the issuing bank.
  2. Capture: Finalize the movement of funds from the issuer to the merchant.
  3. Idempotency: Ensure that retried requests (due to network failure) do not result in duplicate charges.
  4. Refunds/Reversals: Handle post-transaction adjustments.

Non-Functional Requirements

  1. High Availability: The system must handle thousands of transactions per second (TPS) with sub-second latency.
  2. Strong Consistency: It is critical that money is never "lost" or "double-spent" during a race condition.
  3. Auditability: Every state change must be logged for regulatory compliance and reconciliation.

Deliverables

  • Define the core API endpoints for the merchant integration layer.
  • Propose a data model for storing transaction states and ledger entries.
  • Describe the architecture for communicating with diverse, potentially slow, external bank APIs.
  • Explain your strategy for handling distributed transactions and ensuring idempotency.

Constraints

  • Assume external banking APIs have varying latencies and reliability.
  • The system must comply with PCI-DSS standards (i.e., sensitive card data must be tokenized).

Hints

Hint 1

Consider using a state machine pattern to track the lifecycle of a transaction (e.g., Pending -> Authorized -> Captured/Voided).

Hint 2

Use a distributed locking mechanism or a ledger-based approach (append-only) to ensure balance integrity during concurrency.

Hint 3

Implement an idempotency key at the API gateway layer to prevent duplicate processing of retried requests.

Follow-up questions

  • How would you integrate a real-time fraud detection service without significantly increasing transaction latency?
  • How would you handle reconciliation at the end of the day when external bank ledgers do not match your system's state?
  • If the database becomes a bottleneck during peak hours, what sharding or partitioning strategy would you employ for your transaction table?