System design - donation app for a 3 day charity

Рет қаралды 12,175

S. G.

Күн бұрын

Step by step walk through of a system design problem to define a donation app for a 3 day charity.

Пікірлер: 20

@andywang6856 2 жыл бұрын

This video is super helpful. Thank you!

@jiaminghu9126 Жыл бұрын

Wondering why we need to separate out Payment Method Service and Donation Service? I thought we can just pass the payment info from Donation Service to Payment Attempt Service, which calls 3rd party service?

@xxbighotshotxx 3 ай бұрын

Thanks for posting this video. I have a few comments: - The audio is terrible. It comes in an out several times - I really liked your approach to this problem by starting with the functional & non-functional requirements - As previously mentioned, you didn't talk about the 3 day part of the charity service. I'm also not sure if you talked about fast donations as well - This video could have been edited down to not include time spent writing - Some of the writing in cursive is hard to read

@mayankkataruka4344 2 жыл бұрын

Underrated

@namrathasiyer7513 2 жыл бұрын

Could you please clarify the database selection again. How to maintain consistenty with asynchronous or no sql data, if we get duplicate requests? It’s easy with synchronized and sql , we can transaction property or id.

@chivagarg Жыл бұрын

For no sql db you’d need to write app level logic to enforce consistency. Usually this would be done by writing up a “healer” to enforce consistency. There are ways to prevent race conditions as well - eg you could create a “lock” table in dynamodb with a short TTL and rely on the uniqueness of the primary key to prevent both concurrent requests from succeeding

@zen5882 6 ай бұрын

Really helpful!

@zexianwang275 2 жыл бұрын

can we just make donation to payment attempt service call totally async, return customer pending status and send message to queue. notify customer when payment succeed or failed. this can help decouple donation and payment attempt service

@chivagarg 2 жыл бұрын

You can absolutely do it that way and it will probably simplify the design. There are trade offs to be made - attempting payment synchronously might be acceptable if response time & reliability of 3rd party provider is good since it’s a slightly better experience for the user. You could also optimistically tell the user that payment succeeded while you make all payment attempts async. In the small number of cases where payment fails you can send them a follow up notifying them of the failure. That’s actually how Amazon does it

@ariali2067 3 ай бұрын

Considering the fact that we only need to store 3 days' data, should be relatively okay to store within one DB node, do we still need DB partitioning? Can't we just use DB replicas to scale for reads & writes instead?

@Bluespoose 3 ай бұрын

What is the conclusion on the best type of DB to use for this problem? You mentioned that atomicity of a SQL database would make sense given we want our PaymentAttempt and Donations to be in sync. And then you said since we are doing PUTS/GETS, a NoSQL DB would also work. You didn't seem to be clear here

@Bluespoose 3 ай бұрын

how would DynamoDB make sense here as a NoSQL data? That is a key-value store, clearly we have multiple keys in certain tables, wouldn't something like a Cassandra make more sense? The interviewer wasn't clear here

@daddac 2 жыл бұрын

hmm, did not mention 3 day thing at all.

@victorzyin 6 ай бұрын

For the consistency discussion at 44:00, if I'm understanding correctly, the problem is that after several retries the payment can finally succeed, so the payment status = success while the donation status = pending. And eventually donation status will catch up. Why is this bad? It's fine that donation status = pending for a few seconds longer right?

@victorzyin 6 ай бұрын

Oh wait I guess the problem is that the user will get their credit card charged, and still see pending status on the donation status, right?

@idontknooo188 2 жыл бұрын

Is this a tutorial or an interview? The hand writing is so hard to read. Thanks for the video tho

@gautamvpappu8732 5 ай бұрын

I dont understand why you would store two status's for attempt and donation. This is just an unecessary point of failure. Why not just write successful payment attempts to the donation table, and store the status for only the payment attempts

@jjc5258 5 ай бұрын

Assume you want to display all donations an user made, the donation list is read from donations table without interfering attempts table, and it’s good for some analytics requirements if the interviewer wants to add on