NoDB: Processing Payments Without a Database(news.alvaroduran.com) |
NoDB: Processing Payments Without a Database(news.alvaroduran.com) |
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.
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).
and all the technical sophistication is getting around the fact that java was a piece of garbage in like 2008
No, payment systems still have third party systems they rely on. Async programming is there to get around blocking the thread with long-lived tasks where you depend on the result. Removing the database does not remove the potential for all data dependency on long-lived operations.
The article then proposes leaving things in memory, event queues, and hot backups solves all the problems off this flawed assumption. Admittedly leaving things in memory should reduce complexity, but it is not a silver bullet, and you lose robustness to certain failures
Not a great article to be honest.
Edit: Maybe I got this wrong. Maybe the point is that each POS communicates directly with the payment processor, in which case the above applies but wrt inventory instead of balances, and the mention of event sourcing is non sequitur. Also there's still a database, it's just the payment processor's database.