Grokking the System Design Interview, Volume II
Vote

0% completed

​

Step 1: System Definition

A payment can fail in three ways, and only one of them is acceptable. It can be declined, which costs a sale. It can succeed twice, which charges a customer two times for one purchase, or it can succeed with no record, which moves money that nobody can account for. A payment system is built so that the first failure is the only one that ever happens.

This chapter designs a payment platform like Stripe. Businesses use it to accept card payments online

.....

.....

.....

Like the course? Get enrolled and start learning!
Rohit Bhanot

Rohit Bhanot

· 3 months ago

This is extremely text heavy which makes it difficult to grasp an important SD topic. With due respect I feel more effort should have been spent to make it more engaging and enriching rather than dumping large blobs of text. It feels like reading Wikipedia.

Also, Can we really call those bunch of icons as a High Level Diagram without any data flow directions ?

Sorry for the harsh feedback but this definitely looks poorly presented and no way near the worth of pay-walled content !!

Show 1 reply
P B

P B

· 10 months ago

Synchronous vs Asynchronous Processing: The Payment Service does most steps synchronously to provide a result in the API response. We choose sync for the primary flow because merchants (and customers) expect an immediate answer to a payment attempt. 

Since the Transaction DB update is being done by Payment service as part of handling the request itself, doesn't this bring in a lot of failure scenario? For example, what if the Payment Service instance crashes right after calling "Acquirer Connector". The way, the external processor will process the payment, but the Transaction DB would not have any record. Additionally, it means that the client will have to keep a long lasting connection and will be susceptible to connection drop.

Isn't the following alternative present a more dur

Reading Progress

0%

Vote for new content