Amazon Interview Question Software Engineer / Developers
Country: United States
Interview Type: In-Person
Does the POS knows that there are $90 left in the card? I don't think this is practical because this leaves so many security issues... What I'm thinking is that each transaction can contain a "transaction number" which, only changes *if* ack arrives (say, ack_id++). The server can use this id to check if it is the same transaction or not.
I think the idea that sending the remaining balance is perfect. Actually, you can ask the server to do the subtraction for you and send back to POS in an encrypted form. Then the POS can issue the transaction with the encrypted number. This can prevent the remaining balance revealing at POS.
I think,
We can generate unique and encrypted ID for the swiped cards.
Which will go with the amount to be deducted.
Suppose Cloud machine A missed the ack in middle to deliver to POS. But that entry will be in data base containing the information:
Data after transection done in Cloud machine A:
Unique Id <-> Balance Deducted <-> Acknowledgment
encrypted <-> 10$ <-> No.
When Machine B of the cloud will be used to deduct again, then Depending upon the frequent request with the same unique id, we can first of all check, If Ack for the previous transaction is Yes or No. Depending upon the entry.
We can make decisions..
Please add, If It does not make sense..
Thanks..
We can't do that. Because of the case when the customer makes two transaction one after another , both with same amount. In both cases the unique id for cc and the amount will be same, thus ending up rejection of one of the orders.
Just as Chih.Chiu.19 pointed out any design where POS would be aware of card balance seems absurd to me. The problem could be solved by using unique transaction ID(this can still be unique across multiple vendors if we just append POS identify to trans ID) generated at the POS end. Any retries would have same trans id and would be considered as a new transaction.
@Abhishek
You are right. (That's why DB contains one entry of ACK, which will be checked based on the frequency of the operations from the same card)
But at least the person who is swiping the card, Need some kind of ACK before again swiping to make second purchase by considering the first purchase amount has been deducted.
So to make sure, when same card will again trying to deduct the same amount for the same product id, then validating the previous ACK (As this is a frequent call) is YES/NO?
So depending upon the ACK:
1) NO, (Can be the case, Cloud machine A has deducted the amount 10$ but not able to provide ACK to the POS, hence ACK entry for this is NO)
2) YES, (Can be the case, Cloud machine A has deducted the amount 10$ and also provided ACK to the POS, hence ACK entry is YES)
-> In first case, when entry was NO, is the case..
When cloud machine was unable to provide the ACK to POS, So if again same amount deduct request will come frequently.
Machine B, need to see If ACK for the previous purchase for the same product and same amount is YES/NO. If No, It will simply send ACK YES, with some kind of message to provide the POS information, This is the ACK for the first time purchase of the product with amount..and vice versa.
Please add comments.
Thank you..!!
This is what I have in mind ... Because the ack from the cloud is lost, at the POS it is not known that the amount has been debited ... there can be a provision at the POS to request for ack alone when ack is not received ... not sure if this is enough ...
also if possible unique product id can be used for tracking purchase transaction of a product ... this will be known at the cloud and will reject the next swipe and the previous generated ack can be sent ... please let me know if I am missing anything
It is said that "no rollback provision". The product id idea works I think upon modification, to "transaction id" :)
[The idea stems from my Computer Networks course]
The POS could associate a transaction ID to the transaction. After sending a request the POS could start a timer.
If the timer runs out, it sends the transaction request again along with the transaction ID.
The back end ensures that transactions with same IDs are not carried out again.
The ID however, could be hashed by the backend before storing.
(There are many security issues with this approach. But I think the answer would suffice for the interviewer).
Machine A is in cloud so it doesn't save state of a transaction. The next transactin could go through machine B.
- zahidbuet106 February 13, 2013Answer is to send remaining balance in the transaction instead of transaction amount. This is a standard practice in payment systems.