SysPad › Examples › Payment system

Payment system

A Payment Service checks an idempotency-key store before calling the PSP (Stripe) - so a retried request can’t double-charge - then writes the ledger and emits an event for reconciliation and fraud detection.

Idempotency-key checking as a mandatory gate before any external payment call, and one event feeding two independent downstream consumers.

Client Users Load Balancer ALB Checkout Service Fargate Payment Service Fargate Idempotency Keys ElastiCache Payment Provider Stripe AT LIMIT Ledger DB Aurora Payment Events Kinesis Reconciliation Lambda Fraud Detection SageMaker

How it works

Idempotency Keys
The mandatory gate before any charge: the request idempotency key is checked here first, so a client retry of an in-flight payment finds the key and returns the original result instead of charging the card twice.
Ledger DB
The double-entry source of truth: a confirmed charge is written here, then an event is emitted. Read replicas serve the status-check path so it never contends with write transactions.
Payment Events
One event stream, two independent consumers: reconciliation and fraud detection each read it at their own rate, neither aware of the other - the point being you add a third consumer without touching the payment path.

Request flows

Take a payment

  1. Client
  2. Load Balancer
  3. Checkout Service
  4. Payment Service
  5. Idempotency Keys
  6. Payment Provider
  7. Ledger DB
  8. Payment Events
  9. Reconciliation
  10. Fraud Detection

Check payment status

  1. Client
  2. Load Balancer
  3. Checkout Service
  4. Payment Service
  5. Ledger DB

Other interview practice

Open this architecture in SysPad · All examples