This is such an underrated video. This guy needs a big applaud for presenting this architecture. I haven't seen any architects presenting their architecture with this level of detail. I have enjoyed watching this and learned a lot!.
Even I was intgruied by this question. The way I think is that we can modify the design a bit and move the payment service while placing new orders and only when payment is made we add it to the orders stream. Now, from here the discussion might in the direction of how to handle payment failures. Like for example, amazon lets us place the order and if payment failed we have around 3 hours to make the payment again before the order is cancelled. So, here what we can do is that we allowed failed payments to be added to the stream but ship products only which have payment status as success. In case payment is not made in specified time we can then delete the stream for this order. Will be glad to know your thoughts on this :)
@@HarkiratSaluja I agree with your first point we can change design a bit. Essentially how I think about it is that creating an order whether it ultimately gets fulfilled or cancelled is essentially a Transaction which comprises of two steps either succeeding fully or failing fully 1.) Payment 2.) Reducing the count of all Items in Order in the inventory. Since, 2-phase commit is not scalable we need to maintain the consistency with the help of compensating transactions in case of failure rollbacks. These compensating transactions can be implemented either in a Rest/RPC style or in a reactive style with the help of events and Message queues. So, imo we can first store the order in a Relational Db or a persistent cache on order service. Then we. can implement the further flow either in a Orchestrated fashion or in Choreographed fashion. Keeping things simple I'd follow an orchestrated approach where the order service will try to do an order transaction and do a rollback with compensated transaction in case of failures. As a first step we can issue a request/event(depending on rest/reactive style implementation) to decrement the count of items. We can have a time to live for the order under which we expect the payment to succeed. We'll issue a request to payment service and expect a callback/event from payment service within the time period. The payment service itself will have a webhook of third party payment platforms like Stripe which itself may not respond us within the time to live. If we recieve an callback/event from the payment service within TTL then we'll confirm the order and push the event to a Message Queue for order fulfilment or else in case of rest based system we can issue request to a separate order fulfilment service which will cleanup the fulfilled order from order service for further processing. Now, in the scenario where payment failed or we don't get a response/event within TTl we'll mark the order as failed and issue a compensating to the Inventory service for again increasing the count of items. Now, this scenario you mentioned where we give customer 3hr time for payment. I think we can support this as well as the other scenario where we receives the payment status from payment service after TTL by storing the Order in the Order Rdbms till 3hrs. When the payment will be done we'll recieve a callpback/event from payment service indicating payment success. At that point of time if we have those items in the inventory we can mark the order success otherwise we'll have to mark it as a failure and initiate a compensating transaction for Payment return by the Payment service. Let me know if there's any flaw in my thinking
@@prabhatsharma284 One issue I see is that the Order intake Service becomes a single point of failure. What happens in case of the machine going down while processing responses from payment service, database calls, etc.
@@AnkitKhandelwal335 Thanks for asking this Qn. In general in such cases we store the state i.e. commands/events are saved between orchestrator actions. Implementing this from scratch is very hard so we need to use existing implementations such as Aws step functions
This is such an underrated video. This guy needs a big applaud for presenting this architecture. I haven't seen any architects presenting their architecture with this level of detail. I have enjoyed watching this and learned a lot!.
Thanks Pradeep! That means alot :-)
Very clear and nicely explained architecture. Thanks alot for sharing in detail
this video can be renamed as system design prep for e-commerce or similar type of applications
very helpful!
Thank you! ☁️ 😎
How can a valid order be made without an upfront payment?
Even I was intgruied by this question. The way I think is that we can modify the design a bit and move the payment service while placing new orders and only when payment is made we add it to the orders stream. Now, from here the discussion might in the direction of how to handle payment failures. Like for example, amazon lets us place the order and if payment failed we have around 3 hours to make the payment again before the order is cancelled. So, here what we can do is that we allowed failed payments to be added to the stream but ship products only which have payment status as success. In case payment is not made in specified time we can then delete the stream for this order. Will be glad to know your thoughts on this :)
@@HarkiratSaluja I agree with your first point we can change design a bit. Essentially how I think about it is that creating an order whether it ultimately gets fulfilled or cancelled is essentially a Transaction which comprises of two steps either succeeding fully or failing fully 1.) Payment 2.) Reducing the count of all Items in Order in the inventory. Since, 2-phase commit is not scalable we need to maintain the consistency with the help of compensating transactions in case of failure rollbacks. These compensating transactions can be implemented either in a Rest/RPC style or in a reactive style with the help of events and Message queues. So, imo we can first store the order in a Relational Db or a persistent cache on order service. Then we. can implement the further flow either in a Orchestrated fashion or in Choreographed fashion. Keeping things simple I'd follow an orchestrated approach where the order service will try to do an order transaction and do a rollback with compensated transaction in case of failures. As a first step we can issue a request/event(depending on rest/reactive style implementation) to decrement the count of items. We can have a time to live for the order under which we expect the payment to succeed. We'll issue a request to payment service and expect a callback/event from payment service within the time period. The payment service itself will have a webhook of third party payment platforms like Stripe which itself may not respond us within the time to live. If we recieve an callback/event from the payment service within TTL then we'll confirm the order and push the event to a Message Queue for order fulfilment or else in case of rest based system we can issue request to a separate order fulfilment service which will cleanup the fulfilled order from order service for further processing. Now, in the scenario where payment failed or we don't get a response/event within TTl we'll mark the order as failed and issue a compensating to the Inventory service for again increasing the count of items.
Now, this scenario you mentioned where we give customer 3hr time for payment. I think we can support this as well as the other scenario where we receives the payment status from payment service after TTL by storing the Order in the Order Rdbms till 3hrs. When the payment will be done we'll recieve a callpback/event from payment service indicating payment success. At that point of time if we have those items in the inventory we can mark the order success otherwise we'll have to mark it as a failure and initiate a compensating transaction for Payment return by the Payment service.
Let me know if there's any flaw in my thinking
@@prabhatsharma284 One issue I see is that the Order intake Service becomes a single point of failure. What happens in case of the machine going down while processing responses from payment service, database calls, etc.
@@AnkitKhandelwal335 Thanks for asking this Qn. In general in such cases we store the state i.e. commands/events are saved between orchestrator actions. Implementing this from scratch is very hard so we need to use existing implementations such as Aws step functions
Its called Auth + Capture. Initially Payment is only authorized and then once goods are finalized part of Auth or full payment can be captured