Durable mortgage application demo with Temporal

Hello and welcome to Temporal. In today's video we're going to be following on from our quick introduction to our mortgage use case and delve a little deeper into running a demonstration app that allows us to look at some of the Temporal concepts that can make your solutions fully durable. So what are you waiting for? Let's jump in and do a quick review of our mortgage use case workflow. So taking a look at a simplified version of an application process after the application is launched we'll move through to credit checking applicants. The property itself will be valued assuming that successful will reserve an offer in the system. Funds will then be released after a lengthy legal process and finally the applicants will be notified in this case that they were successful. Now, this process does not finish in milliseconds or even minutes, it finishes in weeks or possibly even months. So it's a long running process where lots can go wrong. And if you look at the process again, it will be reliant on third party APIs, possibly returning in an asynchronous way. Of course, these things can fail. Other steps such as property valuation may rely on a human to actually perform the valuation. So we're dealing with lengthy weights and human in the loop. Even within our own system the offer reservation step will be time box to a given time possibly three or six months something like that and of course we have to wait for the legal process to complete which is outside of our control as a bank and that may take weeks or months as well before we can move down through the rest of the flow. All right, so enough of the theory let's now run through a practical example using an application built with Temporal that models a mortgage application workflow and This code for this particular application is available on github I've put the link below so feel free to download and have a look yourself Just a quick tour of what you can see on screen here on the right hand side This is the Temporal user interface. You can see I've had three goals at running applications for mortgages. These are what are called workflows as I've already mentioned. If you drill in and have a look at one of these, you can see all the different steps that occurred in that workflow and we'll run through that now again in our demo. And it's on the left hand side, this is our demo application. So let's kick off a new mortgage application. If I just refresh the user interface, you can see we have a running workflow. for another application. If we drill down or come down to the timeline, you can see we've had two activities run. Activities are calls to external systems, most usually, to get some kind of results. So think of an API call, something like that. If those things fail, then Temporal will retry them as per your instructions, but you don't have to worry about writing that retry code. You'll also see that we're waiting for a credit check to occur, and as part of that, we have an SLA. deadline and this SLA is modeled by something called a durable timer in temporal so even if our worker process crashed workers are responsible for running our workflows the SLA timer would still keep counting because that is taken care of by the temporal server that's where state for this application is stored All right, so if we come down to an application, we can see we've had our submitted step intakes completed. We've requested a credit check. We're just waiting for that now. Now, we've obviously got a failure in terms of our SLA breach. That's okay. The workflow is still running. Our application is still running. Just our SLA happens to be breached. Now, what the workflow is doing now, it's just waiting. Now, this could wait. for an extraordinary long, we could wait forever basically, for the next thing to happen, which is for the result of our credit check. Now, that may be from a system or it could be from a human. In this case, I'm just going to manually approve the credit check. Once we do that, what you'll see happen over in the temporal user interface, you'll see we have this credit check completed step, which is this magenta box, and that is what we call a signal. And you can drill into all this stuff in the UI and see what's actually happening. So you can see workflow execution signaled and we had an approved result. So you get this level of observability with what's happening with your workflows. And upon credit check, the rest of our steps or activities have completed where we've reserved our offer. completed the application and we've sent a notification to applicants and we have a successful outcome. So that's Happy Path. In the next section, we'll look at some failure scenarios. But before we do that, just some concepts to think about. Workflows are the running business process, in this case, a mortgage application. Activities are the external calls for work that can fail. And of course, we'd want to retry those. Signals are things that we can send into a waiting workflow. to do something else and probably not covered here but the front-end application was actually using something called a query to query the temporal server for what the current state of the workflow was and that's how we got these nice updates here now the point with that is there is no other database in this system where we are storing application state that's all coming from the temporal server okay so bear all those concepts in mind in the next section we'll run through some unhappy paths and you'll see where temporal really comes into play when it makes your workflows durable so we'll do that next so let's now come on and take a look at our first failure scenario which is to look at retrying and succeeding after retrying so we'll select our scenario and what's going to happen is we're going to run through our workflow as before the offer reservation is going to work but then the next step is going to fail four times and then on the fifth attempt it will succeed so let's just kick that off and get that running you can see i've cleared down the previous runs of our successful steps everything's running as before we'll just approve the credit check and you'll see what happens down here so reserve offers successful but the complete application step is going to fail four or five times. Now the point here is that you don't have to write any complex retry logic as a developer, you just tell Temporal how you want your activity to retry and you do that via a very simple policy. Okay, so you'll see in this fifth attempt it will succeed and the workflow will just go on as before. So retries as you probably know and love them, but again all handled by Temporal in a far simpler way and again durable because the temporal server is maintaining the state of those retries as well okay so it's not like an in-process retry library that you might get if your worker crashed then you forget at what point you were retrying you don't have to worry about that with temporal because we remember the number of retries that were occurring all that kind of stuff okay so durable retries Great. So the next scenario we'll look at is where this retry completely fails and we then have to compensate the offer reservation in our system. So we'll do that in the next flow. So in this scenario, we're going to exhaust all of our retry attempts and we're going to take it down to just three retry attempts on this occasion. fail on the final attempt, which is three in this case, and then what we're going to do is compensate the offer that we reserved in the mortgage application system. So this is basically the classic saga pattern. So let's start the workflow, come into Tempolio UI, have a look at the running workflow down here. It's the same stuff we've already seen before. We'll approve our credit check and then just keep your eye on what's happening down here. So reserve offer has been made, so that's done. and our complete action we've only got three retry attempts it's going to fail outright on all three of those which indeed it does and you can then see we have this new activity release offer so we go back to our offer system and release the offer that was made so classic saga pattern so the point here kind of mentioned already if your retries fail you can account for that in your code now we retried here maybe you wouldn't want to retry it doesn't matter same principles apply and of course you can drill into this and you can look at why it failed and where it failed all that stuff so you have full observability fantastic and you can even see up here that's the yeah this workflow failed okay unfortunately but again fully observable now in the third and final failure scenario what we're going to kill is the actual worker the process that runs the the workflow and you'll see how that manifests when we do that but we'll uh you'll do that next so in this third and final failure scenario we're going to look at what happens when the actual Worker process dies and the worker process is responsible for actually running executing the workflow Whereas the temporal server is responsible for maintaining the state of the running workflow and you'll see that nice separation of concerns When we come on to doing that. So let's start another application. We've got a running Application as before I'm going to quickly kill the worker and I'm just going to do that using the docker compose Kill work up That's done now. Okay, the worker is gone, but you'll notice that the temporal workflow is still going most notably the SLA timer is still counting down because that's managed by our temporal server So again, we have this concept of durability. So even though our workers gone the workflow is still captured and being held in the temporal server. Now you can even see in an application which is using a query to get the state of the workflow. It's getting that because it can still talk to the temporal server but it knows at this point the worker is not available or the ARN worker is available. So it's saying it's showing the last known state of the workflow, workflow state safely held by temporal and processing will continue. when a worker reconnects. What we can even do, in fact, is submit the credit check because that signal is going to the temporal server ultimately. You can see that was received, but nothing else can happen now because there is nothing else to perform the rest of the workflow. Now, of course, in terms of recoverability, you could use standard techniques to recover workers. I'm doing that manually, of course. The point is that when a worker becomes available, events are replayed from temporal server, so we don't re-execute steps that we've already done such as intake or request credit check we start from where we left off so docker compose dash d and it's worker v1 that's okay so that's up and running now you can see that our workflow just keeps going reserve offers made complete applications made send notification is done and it ran to completion so the idea that the actual process running your work dies not an issue upon recovery everything's replayed and you go from where you're left off. All right, so that's enough of the demo. Let's maybe take a quick look at the solution architecture just to kind of get your head around that and then we'll move on to wrapping up. So let's take a look at the standard solution components you'll find in a temporal solution. At the heart of it, of course, is the temporal server, which gives you that durability, gives you that persistence for your workflows, and as you would probably expect, there is a database attached to that. I was running a local development version of Temporal. If you're wanting to stand this up in a production context, you can either back that off to Temporal Cloud, which is our commercial offering, or you can self-host the open source variant yourself. Functionality-wise, they are exactly the same. It's up to you how you want to do that. Now, in terms of the applications that you build, of course, that will vary greatly on what you're doing. In terms of the application we were looking at today, again, the code is on GitHub. the description below you can find the link to the repo we had a web UI with an API which effectively acts as a temporal client so it would kick off requests to start workflows it would send in signals to the workflows it would retrieve the results of queries things like that and display it on the web front end on the other side of the equation we have a worker and the worker goes to the server understands what workflows it needs to execute and will do that. You could have one worker, many workers, scale them up, scale them down as your workloads demand. And again, the workflows are your orchestration for your business workflows basically. Activities again are the discrete units that call external services, APIs and databases and things of that nature. So super high, super quick overview of a given temporal solution. Well, that brings us to the end of another video. I hope you found it interesting and informative. In the next video in the series, what we're going to do is deep dive the code for the demo app that we ran through today so you can start to learn how to build all of this stuff yourself. Now, if you can't wait that long, then I'd suggest you jump over to the website, try any one of our quick starts. We support all of the languages you can see on screen here, and you can start building temporal solutions yourself. Other than that, if you had any thoughts on the video, please leave it in the comments below. But until the next time I see you, stay safe, take care, and I'll see you again very, very soon.

See Temporal in action as we walk through a durable mortgage application workflow and explore how it behaves under both normal and failure scenarios.

You can get the code for today's demo here: https://github.com/temporal-sa/mortgage-application-demo

Scenarios covered:

• Happy path workflow execution
• Activity retries recovering from transient failures
• Permanent Activity failure triggering Saga compensation
• Worker crash and recovery with no loss of workflow state

Whether you're new to Temporal or curious about durable execution, this demo provides a practical introduction to how Workflows, Activities and Workers work together to build reliable distributed applications.

Time Codes
- 0:30: Quick overview of example mortgage application flow
- 1:40: Happy path demo - introduces: workflows, activities, signals and queries
- 5:24: Retries with recovery
- 6:57: Activity failure with Saga compensation
- 8:28: Worker crash, running process failure, recovery and event replay
- 10:58: Solution components
- 12:20: Final thoughts and next steps
---
Temporal is the simple, scalable, open source way to write and run reliable cloud applications. 

Learn more
Blog: https://temporal.io/blog
How Temporal Works: https://temporal.io/how-temporal-works
Community Slack: https://temporal.io/slack

Developer resources
Code: https://github.com/temporal-sa/mortgage-application-demo
Docs: https://docs.temporal.io
Courses: https://learn.temporal.io/courses
Support forum: https://community.temporal.io