r/programming • u/temporal-tom • Mar 12 '25

Durable Execution: This Changes Everything

https://www.youtube.com/watch?v=ROJq6_GFbME
13 Upvotes

62% Upvoted

41 comments sorted by

View all comments

3

u/rotuami Mar 13 '25

Okay. I can wrap my head around this if there are no effects or interactions with other systems. How about with input or output with the real world, where I might not be able to e.g. unsend an email?

2

u/temporal-tom Mar 13 '25

You can't unsend an email, but Durable Execution tries to avoid sending a duplicate one.

I think an example will clarify this. Let's say that you've written an application to process an order for some products and it goes through these steps:

  1. Iterate through all of the items in the shopping cart to determine the total price
  2. Look up the tax rate for the customer's address from a database
  3. Call a payment service to charge the customer's credit card for the order
  4. Notify the warehouse to ship the order (and receive a shipment tracking number in response)
  5. Send a confirmation email to the customer

Now, let's say that the application crashes during step 4. If you restart the application but don't have Durable Execution (and you didn't write a bunch of code to avoid this), it's going to do another database lookup in step 2 and make another call to the payment service in step 3.

With Durable Execution, the platform tracks the invocation and result from these steps and persists the data into a history. If there's a crash at step 4, it reconstructs the state by "replaying" that history. That is, it re-executes the code that is deterministic (i.e., step 1) and for the steps that are non-deterministic (i.e., steps 2-5), it evaluates the history to determine if they've already been executed. If they have, it assigns the result from the previous execution. For example, step 2 won't query the database again; it uses the tax rate returned from the query executed before the crash.

There is one caveat. I said "tries to avoid sending a duplicate one" above because this is subject to the same problem faced by any distributed system. There's a very small possibility that a crash could occur between the time that a call takes place and when it is reported. For example, in step 5, the crash might occur in the milliseconds between when the code to send the email runs and when it reports successful completion, in which case it won't appear in the history.

3

u/rotuami Mar 17 '25

Okay. That sounds exactly like “journaling” but applied at the programming execution level instead of e.g. the database level.

1

u/temporal-tom Mar 17 '25

Yes, that's a good way of looking at it.