Today is Cyber Monday. Here is how money moves when you click the Buy button on Amazon or any of your favorite shopping websites. 1. When a user clicks the “Buy” button, a payment event is generated and sent to the payment service. 2. The payment service stores the payment event in the database.
I have trouble wrapping my head around why we need ledger and wallet. In my mind these are all derived information that shouldn't be part of the payment flow. At best these just need to be updated asynchronously to be used for e.g. reconciliation as mentioned. Can you explain why you design them to be part of the payment flow?
How will the system remain in consistent state if there's a failure in wallet service or ledger service?
Should there be a synchronous transaction among all the services involved? If yes, how would it be implemented.
You might also wanna consider gift cards and order cancellations in this aspect? What are your thoughts?
This is REALLY superficial. Any good interviewer would dig deeper into the DB, whether the ones shown are the same or different, SQL/NOSQL, txn failures modes, database schema etc. This diagram may be ok for an intern applying for a company no one has heard of, but beyond that, it's insufficient.
very useful design flow：thanks
Which is the payment executor in this scenario ?
the payment service is the api to connect between mobile and Backend. ? Payment executer is the use case or BE service ? If we want to create the payment sdk, what kind of certification process needed ?
How and when would Amazon/seller get the money for the sale? Can you elaborate on the settlement process a bit please?