💬
✉️
📸
▶️
Loading…
Loading…
Open SystemDecoder on a larger screen to build systems, run simulations, and inject chaos.
Daily Challenge
SystemArena
5
Questions
Think Deep
1×
Daily Shot
5 sharp system design questions. One attempt daily — streaks, XP & leaderboard.
What's waiting for you on desktop
Live Simulations
Watch latency spike, queues fill, and nodes fail in real time. Every slider change is instant.
Visual Architecture Canvas
Drag nodes, draw edges, and build any distributed system topology from scratch.
Chaos Engineering
Kill servers, introduce packet loss, throttle CPUs — and watch your system react.
Real-time Insights
Throughput, p99 latency, error rates — all charted live as your simulation runs.
40+
Concepts
<1s
Feedback
∞
Replays
"The best way to understand a distributed system
is to break it."
Payment
💳
Money must never be inconsistent.
Idempotency · Ledger · Webhooks · Reconciliation
Request Flow
Money must never be inconsistent
Unlike a dropped search query or a missing feed post, a dropped payment is catastrophic. The user was charged but received nothing — or worse, charged twice. Every design decision in a payment system prioritises correctness over speed.
Three failure classes
(1) Duplicate charges — client retries after a network timeout but the first request already succeeded. (2) Lost payments — request arrived but the system crashed before persisting. (3) Phantom charges — charge recorded but downstream fulfilment never triggered.
What we'll build
A system that handles all three failure classes using , , an immutable , and a nightly .
Why We Need This
Payment networks like Stripe and Adyen are themselves distributed systems — they guarantee at-most-once processing on their side, but the connection between your service and theirs can fail at any point. Your system must be designed for partial failure at every layer.
Key Insight
The golden rule: it is always safer to fail a payment than to process it twice. Design every layer with that constraint in mind.
Overview