0:00 All right, so before we begin actually creating our 0:04 workflow, we're gonna create the supporting services 0:08 that 0:08 the workflow actually uses. So in this application, 0:12 again, we're going to have an ordering system 0:14 where we have an inventory 0:16 service that manages the inventory, order service to manage the 0:19 order, payments for payments. 0:23 And all of these are going to be orchestrated as part of the workflow. 0:26 When a user places an order, there are several steps that we 0:30 need to execute. For example, we need to charge the user's payments 0:34 using the payment service. We then need to reserve the stock using 0:38 the 0:38 inventory service, and finally, send the user an email to 0:42 request a review. So all of this is a workflow that 0:46 we want to handle success and failure cases, and we're 0:50 going to see how this can work across multiple instances and 0:53 potentially even services. So to begin, let's start off with 0:57 creating our payment service, which is going to take care of actually 1:01 charging the user. Now, recall we set up our payments to 1:05 charges table inside of the database, and this is where we're gonna 1:09 record our user's payments and their refunds if the payment 1:13 has to get rolled back, which will be a key benefit to using the 1:16 workflow, is that when a failure occurs, we want to refund the 1:20 user, a very common use case, and we're gonna have all of this 1:23 automatically 1:24 done with retries out of the box. And so we're recording any 1:28 payments or refunds that do occur on our database. 1:31 Now, what I wanna firstly create is the 1:34 paymentprovider.client, and this is gonna be 1:38 the actual implementation for the payments. 1:41 And then we'll have a separate payment service that then injects that 1:44 implementation and keeps it more abstract. 1:48 And so in the provider, this is where we'll have the lower level
The rest of the transcript is for members.
Sign in 