Home › Scenarios › Payment processing
System design scenario
Design a payment processing system
Advanced
Every request goes to a slow third-party payment provider, including status checks that could be answered locally. The provider limits concurrent calls, and aggressive retries turn every slowdown into an outage.
▶ Simulate this designThe goal
Keep p99 < 1500 ms and error rate < 0.50% at 5,000 req/s for 10s.
- Peak load
- 5,000 requests per second
- Traffic mix
- 60% reads, 40% writes
- p99 latency
- under 1500 ms
- Error rate
- under 0.50%
The starting architecture
The simulator opens with this design. It is deliberately too weak for the goal: run it and watch which component saturates first.
- API LB (Load Balancer, 2 instances): API load balancer.
- Payments service (Service, 10 instances): Payments service: creates charges with idempotency keys and answers status checks.
- Payment provider (External API, 5 instances): External payment provider: slow (~300 ms), with a limited number of concurrent calls.
How to approach it
The hints unlock one at a time in the app. Try the design yourself before reading them.
Show the hints
- Only charges (writes) need the provider. Status checks (reads) can come from your own ledger.
- Route reads and writes separately: select an edge and set what it carries.
- Buy more provider concurrency, and make retries safe: idempotency keys, a retry budget and backoff.
What the simulator shows you
SimLoad models every component as a queue with real capacity, latency, timeouts and retries, so you see utilisation, p50/p99 latency, errors and monthly cost change as you scale. Insights name the bottleneck in plain language, and the capacity planner sizes the fix. A reference solution that meets the goal is verified by automated tests.
▶ Try it in the simulator