UPI System Design Mock Interview with Gaurav Sen & @sudocode

preview_player
Показать описание
The UPI (Unified Payment Interface) design is curious because very little of the implementation is on the designing body's side (NPCI).

You can think of UPI as a protocol or standard, an API contract, that must be followed by all banks to allow UPI transactions. The standardization of communication allows banks to talk to each other seamlessly. As long as the APIs provided do what is expected of them, we can ignore the internal implementations of these banks.

Let us see how fund transfers work in the Unified Payment Interface world.

Use the coupon code of SUDOCODE to get a special discount.

You can follow me at:

#SystemDesign #InterviewReady #UPI
Рекомендации по теме
Комментарии
Автор

Watched it twice till now, still feels like there lots left to understand. Not getting bored.

VictorKun
Автор

It would have been better if the interview was systematic like
1. how a user is registered with GPay
2. What happens when user A transfers amount to user B
3. how merchant raises a request to pay amount

tapasyayadav
Автор

the overall discussion is little confusing

joydeeprony
Автор

This feels more like a Product Manager interview where all things except technical details like scaling, resiliency, reliability, databases are being discussed

AmanSingh-wvno
Автор

Guys. This is not how UPI works. If it is more toward making an interview discussion then it's okay. There are technical inaccuracies in this. Should not just wing it even in an interview.

rpwarp
Автор

Npci is governing body, so all the banks have to go through npci where npci (government body) have full controll. If all banks talk to tach other directly then it's blockchain architecture.

vijayshankarguptavijaygupta
Автор

Great reference!!
Now I am subscribed to Sudocode

rishiraj
Автор

At 15:00 what I think about NPCI acting as middleware is that it might need to check the VPA (Address) of both users might be like VISA, MASTER and Rupay connecting with every single banks and then our requests are handled by them, i think NPCI might have a similar thought as it connects with certain bank and then checks the VPA and handle requests

abhiawate
Автор

NPCI uses Dynamically generated HashKey to establish the Identity of the user with the help of paysecure which makes auth initiate api call

vickykamble
Автор

@GauravSen, A few points that I want to add :
1. Transaction flow (at around 11:00 timestamp) is missing validating of recipient VPA which should be done by NPCI. Also, NPCI should get the account number/IFSC details of the recipient VPA before the actual transaction begins.
2. Post validation of recipient VPA, the actual transaction should be started by NPCI which should include both the sender bank and the recipient bank.
3. PINs are not stored at NPCI and are only stored at Bank's end.
4. In the case of pull payment also, before HDFC bank, the request should go to NPCI, then the sender PSP server, then actual payment should happen on user action.

Also, At one point, You mentioned that NPCI should not work as a router/intermediate but should only work for authenticating users. I think the current way NPCI has more control over the payments. Second, it can manage failed transactions better in this case. Also, any disputes/complaints related things can be better managed this way.

There is a video on the channel "Learn Payments" (not promotion) that I watched a long time ago and found very very useful to date to understand the components of UPI and the transaction flow of UPI. I would recommend anyone to watch that great explanatory video.

abhishekbadoni
Автор

You guys are doing really amazing things..
Worth watching.

sagars
Автор

Npci is adaptor here, all banks can not be bind to each other, they are decoupled.

MukeshSainiprogrammer
Автор

as per my
knowlege for banking transactions HSM encryption/decryption is used by all parties. pls correct if i m wrong

harshinsan
Автор

Very importana part missed here is - How the millions of request handled ? All reuqest are critical . That should have been part of discussion intead of going deep into NPCI and stuff. Those are part of standard implementatoin but scaling these type of application with fault tolorecne is more important.

sohanbafna
Автор

Not done well. The diagram is confusing and the thoughts are all over the place

HorrorInsides-dmfc
Автор

why would NPCI store private keys?? shouldn't this be on the user app?

akashdeepjayashankar
Автор

Thought:

1. Payment request along with PIN (maybe hashed) is taken by NPCI from the UPI App
2. NPCI does validation along with bank and account number identification for both sender and receiver
3. NPCI initiates a transaction (atomic) with first to deduct the amount (request to sender bank with PIN), then to the receiver bank

This way:
a. Responsibilities are decoupled. A bank has to just implement two things to be UPI enabled: 1. Validate PIN and deduct the money, 2. Receive the money and credit the amount to bank account.
b. NPCI is managing the whole UPI complications and infrastructure.

I agree NPCI will be single point of failure, but I think it's okay, they are anyways the middleman.

arpanbag
Автор

Big fan of Gaurav and Yogita but guys this could have been bit structured. I know u guys want to simulate a real time scenario of an interview but it is better to make it structured and prepare in advance before hand since lot of people learn from u both.

aashishgoyal
Автор

Just saw 7-10 mins of this video and subscribed your channel. You really doing good for the tech community.

arunsolanki
Автор

@gauravsen @sudocode
Hi Gaurav, please don't mind, I'm just giving an honest feedback that this interview experience seems really beginner level.
I think Yogita did her best trying to steer the discussion.

You guys just discussed about component diagram of payment connection.
I think, there's a lot you could have discussed about this so we could get some more picture like
how do you onboard a new user/new_upi_id?
how much data needs to be stored? (optional, we all know it's gonna be huge)
what kind of DB would have been used for various segments? and why?
what kind of sharding key you could have used?
will it be a good idea to make it into an event-driven architecture?
any discussion how would you rollback if a payment fails?
how would you prevent double payment?
how would the calls go? sync? or async?
It's just been a month or two since I started learning about System Design and have not given any interviews, you guys are in this for way long, so I maybe wrong, but I think you could have increased the interview length to 45 mins, and could have provided a lot more depth into various aspects.

Although I like your playlists Gaurav, and recently started watching Yogita's videos as well, she brings an LLD aspect which helps relate things a lot! Keep up the good work both of you, and Please Take This As A Contructive Feedback!

shubhamkhurana