Payment System

A payment system has one property every other system can live without: it has to move money exactly once. If a redirect service drops a request, the user hits refresh. If a payment service drops, double-fires, or half-commits a request, someone is out real money and a regulator eventually wants to know why. The hard part is that the failures you must survive are not exotic. A client retries after a timeout, a bank call hangs for four seconds, a worker process dies mid-charge, the ledger gets slow under contention. All of those happen on a normal Tuesday, and especially during a flash sale. This guide builds the design the way you should build it in an interview: start from the requirements, do the arithmetic, then assemble the architecture piece by piece and justify every capacity number. The target is the same reference the SysGym simulator grades you against: 6,000 checkouts per second spiking to 12,000 during a flash sale while PSP callers die and the ledger slows, with a hard floor of 99 percent of payments completing and zero double-charges. By the end you should be able to derive that design yourself, not memorize it.