I've never worked in payments, but I think you can't take too many lessons from trading infrastructure for payments infra due to the way the scaling works.
In trading infra you are dealing with fairly finite number (100s to 10,000s) of instruments trading very large volumes of transactions (thousands to billions), so you can shard by instrument, dedicate CPUs, keep everything in memory and voila. Cross instrument consistency is generally not as much of a problem, depending on what part of the stack you are working on (order book / matching engine / market data feed / order router / position calculations / etc ).
With payments I'd imagine you are dealing with millions of payers, millions of payees, and 10s - 1000s of payments each.
not sure why you're downvoted, the point is quite valid. I worked on both sides. They may seem similar from afar over the big picture but largely distinct in details and thereafter scaling tricks.
Trading on both buy and sell sides are highly structured data, and post trade requires high level of interpolation among data entities.
Payment processing data unit are somewhat unstructured / document based (payer/customer details, payment intent, plans, gateway infos..), but each payment object are quite isolated from each other. Post payment there are some interpolation if system is dealing with payouts account ledgers, but far from level of trading risk management (particularly derivatives).
In trading infra you are dealing with fairly finite number (100s to 10,000s) of instruments trading very large volumes of transactions (thousands to billions), so you can shard by instrument, dedicate CPUs, keep everything in memory and voila. Cross instrument consistency is generally not as much of a problem, depending on what part of the stack you are working on (order book / matching engine / market data feed / order router / position calculations / etc ).
With payments I'd imagine you are dealing with millions of payers, millions of payees, and 10s - 1000s of payments each.