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
This feels more like a Product Manager interview where all things except technical details like scaling, resiliency, reliability, databases are being discussed
Agree. I also agree that designing such systems need some prior domain knowledge like how 2 banks interact with each other to complete a transaction (Ex Swift) but the video should have been more professional.
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.
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.
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
VISA and MASTER are generally called schemes, and I dont think schemes would need to take part in this. But there are several authentications to be made when we deal with the real life scenario.
@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.
thanks for this detailed comment, as I understand, once the NPCI receives the request from the Payer PSP, it forwards the request to payee PSP. So, if recipients VPA is validated at NPCI itself, what's the use of forwarding it to the Payee PSP. Kindly let me know on the same @abhishekbadoni9
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.
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.
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.
@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!
The exact flow for this design boils down to the ultimate question - who stores that one PIN(Bank or NPCI)? Probably this information isn’t out yet, that’s why video became bit confusing in the middle. As someone who works for a bank, to me it makes whole lot sense if NPCI stores that PIN even though it makes NPCI a single point failure. Because if you see, that PIN remains same for different payment IDs a user has in the UPI app I.e that PIN remains same for different bank accounts(say HSBC and ICICI) a user has in the app. If each of these banks store that PIN for that user, then ICICI also stores PIN of that user for HSBC account and vice versa which is not a desirable situation. NPCI alone storing and authenticating the PIN is desirable and once authentication happens at NPCI , it’s like existing e-mandate - bank has to deduct money.
Was npci supposed to be a 3rd party service? After the capacity estimation step shouldn't we have established read and write ratios and suggest a database type for npci? Who maintains the payment history? Apart from the technical details this seemed like a borderline passing situation as it was kind of confusing
I agree, there is lot more to explain like state machines, raft protocols for propagating the states to different machesin...this interview is good, but I thnk it focuses more on Authentication which is security focussed.
Why message is sent when we try to register UPI and what kind of message is sent? Also, why do we need to have the sim card inserted for upi transactions?
Shouldn't NPCI just have domain resolution. For eg. mapping should be like {@icici, x:x:x:x}. The actual userId should be maintained with the bank only. For eg. ICICI should keep a record for Gaurav@ICICI.
Gaurav performed bad in this interview may be 1 out of 5 and this is not at all structured. Unable to understand anything and I feel alot of things are missing from the technical standpoint.
@gaurav: I think you were 2 out of 5 . There are many technical aspects which could have been covered considering HLD . This still seems to be more of functional discussion.
@GauravSen Will it not be more feasible that NPCI works as central authority for actual transactions flow and not just name verification? 1. user A(UPI_A) opens PhonePe(Payee PSP), initiates a request to transfer Rs 100 to UserB(UPI_B) 2. PhonePe calls NPCI API - payMoney{UPI_A, UPI_B, authenticationPin} 3. NPCI maintains central repository around how the UPI Id of user is associated to which bank and additional required bank details. 4. NPCI goes to bank of userA and initiates debit request for Rs 100. 5. NPCI gets ack that amount can be debited from userA bank 6. NPCI goes to bank of userB and initiates credit request of Rs 100. 7. NPCI gets ack for amount credit to userB account. 8. NPCI sends notification to userA and userB PSP 9. Payee PSP send notifications to both users for debit and credit. There will be additional step for authentication. I'm not sure of UPI's actual implementation but above made more sense.
+1, There should be central authority orchestrating the transaction. else who knows if BankA actually sends money to BankB and not return fake success response to app. And NPCI should be the one notifying to each party.
@@AnshuBhuwania You have an account with bank A. If they are going to fake the transaction, you can take them to court, but YOU created an account with them, so you obviously trust them with your money.
Instead of bank sending request to NPCI to check whether B id is valid or not this seems more logical.But i think the debit will be done by bank only once step 4 is done..not sure
Generally gaurav lacks structure in all his videos. After a long time I thought I’ll watch one and this is as confusing as the others. He doesn’t take feedback either. Had bought his corse and it was a complete let down.
@GauravSen @sudoCODE In the collect request flow, Dont you think Banks have additional responsibility to handle UPI providers(Gpay, phonepe etc) specific logic as well (sending the collect amount, transaction status notifications to the respective UPI provider)? Do bank servers store UPI server details (resolution from abcd@axl to phonepe etc) for sending the notifications or it contacts NCPI for those details?
When we open GPAY and transfer money to a Id say VPA02@Oksbi from VPA02@OKHDFC , it will ask for the PIN Are you saying that the PIN should be send to HDFC not NPCI ?
Here's my POV on UPI The authentication is nothing but your UNIQUE PHONE NUMEBR, your phone number is your digital signature/identity Banks and UPI app Authentication: 1. you add your bank account to UPI app 2. your UPI app send a random string to your bank from your SIM using SMS (not just any SIM, the SIM must be a pre registered SIM with the banks) 3. your UPI app also sends the same string to bank from with in the app 4. your SMS key and the phone number will/has to be matched 5. your bank account gets added to your UPI app 6. details are forwarded to NPCI? Transaction authentication: 1. you initiate a request with your app 2. app initiates a transaction with the bank 3. in the background your UPI app may also check for the receivers UPI app 4. bank says I found the details of the receivers bank to your APP 5. UPI app may say that's great I also have the details from receivers UPI app 6. both are verified and transaction gets processed 7. details are forwarded to NPCI? Errors 1. after initiating the transaction bank may say that your bandha doesn't have enough money to transfer to your UPI app 2. your/receivers bank may be under maintenance and for the time being your/receivers bank may be having difficulty sending/receiving money to other bank 3. the basic UPI app/Bank authentication might be having problem from your UPI app side because they are under maintenance (lately PhonePe is struggling while the transaction is getting successful elsewhere) 4. huge transaction messages in the que (message broker?) and time out 5. lack of constant internet connectivity from the customer end? Sorry but as much as I wanted to watch the interview I simply could not for some reason, cracking an interview is one thing and having knowledge is another thing, no wonder people go for proxy interviews and survive in the IT for the career entirety..
