Provide your take on what will you choose and why? Additional context: Transaction will actually happen on different exchanges. You do not control their timing and latencies. My take: I will do async processing with a queue for orders to be executed and then another with result. Client will get id of order and client app will get notification once order is confirmed. This allow better scaling and fault handling. Blind tax Yoe:14 Tc: 260
What company asked this? I am guessing they would like to hear trade offs of both. Synchronous is less likely to incur data loss at the cost of not being as performant and scalable.
I don't think any transaction processing arch should or could be sync. Unless it was a financial system that was very resilient and had an astronomical number of 9s you should always go async.
You have no idea how I wish card authorizations were asynchronous
Definitely Sucks on the backend, because you still need to interface with really old systems. But for the end user async should be the default
Async
Async, since you even mentioned it is going to happen on a different exchange and no control over latency. Synchronous would yield bad performance and also user experience
Both. Persist the transaction event and then event source async.
World Conflicts
13h
510
Israeli precision-guided munition likely killed group of children playing foosball in Gaza, weapons experts say
India
14h
589
'Hindutva': The Radical Hindu Ideology That Seeks to 'Push Christianity Out of India’
Health & Wellness
4h
594
Anyone else have a bloated belly until a huge fart deflates the belly back to normal?
World Conflicts
11h
450
Is "From the River to the Sea" So Wrong?
Personal Finance
8h
945
Thank you AAPL and NVDA
Async. The same way Amazon payments does transaction processing
Can you please list some benefits too? Trying to gather trade offs and scenarios when one is better than other. Thanks in advance