Temporal — Workflow Orchestration for Distributed Systems

Hello everyone, today I will be talking about Tempolo which is a workflow orchestration engine for distributed system. So let's start with the problem. We are all facelessly. Imagine you are building an e-commerce backend. When a customer pays an order, you need to do four things in sequence. First is to charge their payment. Next is to reserve the inventory in the warehouse. Then send a confirmation email. update your CIM or analytics. Now what happens when the step 3 fails? The email service is down, the customer has already been charged, the inventory is reserved but they never get a confirmation email so that is a problem. So how do we normally fix this? The obvious solution is really have very complex the first option We do time except with manually ties but what if the entire server crashes between step 2 and step 3? Your retire logic dies with the process. The customer is charged but the system has no memory of where it stopped. Second option, you track state in a database. Add an order status column and write a project that scans for a stock order every 5 minutes. Now you're building and maintaining a customer state machine that get more complex over time. Third option, message queue like Kafka or LabVidMQ. Better but now you need these later queue you have to handle, idempotency, message ordering and each step needs its own consumer. Debugging becomes a nightmare. The core issue is you end up spending more time on reliability infrastructure than on actual business logic and it's never truly reliable. So, this is actually the problem that Temporal was built to solve. Temporal is an open source workflow orchestration engine. It was created by former Uber engineer who originally built a system called Cadence internally at Uber to handle exactly this kind of distributed workflow problems at massive scale. The core idea is called Delable Execution. In simple terms, you write your code as if feature doesn't exist. and Temporal handles retires state, persistent and cache recovery for you automatically. It is important to understand that Temporal is not a message queue. A message queue like Kafka or RabbitMQ moves data between services. Temporal orchestrates the entire process. It knows where you are in a workflow, what is complete, what is pending and what needs to retires. There are three building blocks you need to know first. Workflow, these are the orchestrator defining the sequence of steps. Activities, these are the actual work like API calls, database write, sending emails and third, Worker, these are your processes that actually run the code. Temporal supports SDKs in Python, Go, Java, TypeScript, .NET and PHP so you can use whatever language you are comfortable with. So let me show you this. On the left, the traditional approach, you see the messy tri-exit block that manual database state updates after each step. The low-back logic, if something fails, the comments are seen. What if the server crashes here? And the question, do you try how? At the end, this may be 40 or 50 lines of boilerplate just for error handling on a full-step process. On the line, the same flow interval, it is just full. Sequential execute activity calls and that is no try exit no database data tracking no cron job no no backlog if the email service fails temporal retires is automatically based on your retires policy if the server crashes in the middle temporal replays the event history and resumes exactly where it left off the payment won't be charged twice twice temporal already know it succeeded This is what write code like failure done actually look like. And how it works? The answer is event history. Every single thing that happens in a workflow gets recorded as an event. So first event is a workflow start. Next is the activity schedule for charge payment. Event is activity compute for charge payment and so on. Now, let's say the worker crashes after the event 6, the setting man activity was scheduled but never complete. When the worker comes back online, temporarily replace the event history, it reconstructs the state from event 1, 2, 5, and here's the crucial part, it does not re-execute those activities. It already knows charge payment and reserve eventually succeeded, it just rebuilds the workflow state from the stored result. Then it resumes from the event 6, to send email activity get retry. If you have taken a database source, this is actually the same concept as write ahead logs but apply to your entire business logic instead of database transactions. Here is how the architecture works. There are three components. First, your app or the starter. This is the client that kicks off a workflow in a real app. This might be trigger when someone clicks and clicks and clicks on your website. Next is the temporal server. This is the brain. It perceives the state of every workflow, manages task queues, and tracks the event history. You can either self-hold it or use temporal cloud. And the next one is workers. These are your processes that actually execute the workflow and activity code. The temporal server dispatches tasks to worker via task queues. One crucial thing to understand, temporal never runs on Never learn your code, it orchestrates it. Your code runs on your worker in your infrastructure with your security context. Workers can also be scaled independently and deprived with zero data. So you might be wondering how does Temelo compare to other tools you may have heard of. First one is the Apache Airflow. Apache Airflow is probably the most well known. It's a DHE scheduler designed for batch data pipeline and ETL jobs. You define workflow on Python DIGs. It's great for scheduled data processing but it's not designed for real-time transactional workflow like auto processing. Next one is Celery. It's a task field for Python. It's good for simple async tasks like sending an email in the background but it's not workflow orchestration. It doesn't have built-in state tracking or repeat capabilities. Next one is AWS state function. It's a managed service from AWS. Unified state. Machines in JSON, it works well if you fully in the AWS ecosystem, but it comes with vendor, login, and indigestion definitions can get verbose and hard to maintain. Next one is Prefect. It's a modern alternative to alpha, beta developer, FCS, laser, Python, decorators, but it is still primarily focused on data pipeline, not business process orchestration. So the template stands out because it is specifically designed for long running, follow to the land business processes with deliver execution. You write workflow in real programming like it not YAMO or JSON and you get automatic crash recovery built in. So let's be balanced about this. Every tool has a takeoff. On the ProSize, deliver execution with automatic crash recovery. This is the big one you can write. workflow in familiar programming language not YAML no DSL to learn automatic retires with config label policy per activities through observability to the web UI where you can see every workflow, every step and every retires. It supports multiple languages through Polygon SDK and it is fully open source with very active community. On the con side The learning curve is steeper than simple task cubes like Slele, you do need to run a separate terminal server. It's an additional piece of infrastructure that is a determinism constraint on workflow code. You can use random number or datetime.now like that directly in workflow because it will break replay. Self-hosting in production requires operational effort. The ecosystem is smaller compared to mature tools like AFO or Slele. and there is some performance overhead from processing every event in the history. For Moz, Wagon and Microservices use case, the post will always be gone. But for simple async tasks, selling might be sufficient and for batch data pipeline, info or prefix might be a better fit. Let me show you how it is easy to set it up. You just need a few things first. In this example, we use Python 3.1. Next is the Tempolio package. Third one is Tempolio CLI. Next one is the WebView icon automatically when you start the server. And Docker is optional. That's it. T-Terminal Windows. And one browser is your computer development setup. Here's how the demo project is organized just for Python files. First one is the activities.py. This is where you define functions that do the real work. API calls database write, sending emails, these are the things that can fail and temporal view retires them automatically. Second with workflow.py, this is the orchestrator, it defines the order of the steps. One important loop, workflow code must be deterministic. No random number, no direct date, time calls, or non-deterministic work goes in activities. Third one is workers.py. This connects the temporal server and registers your workflows and activity. It posts for tasks and executes them. And the last one is the starter.py. This is the kind that kicks off a new workflow execution. Now let me show you this in action. Okay, now let me walk you to the demo. So here's a temporal demo file. Temporal demo folder that I mentioned earlier. starter, worker and workflow files. First step, we need to start the terminal server. Let's start it. Okay, you can see the server is running the UI on the localhost, port A2.3.3. So let me refresh it. Okay, so you can see that there is still no workflow running in the namespace. So I will run the workflow. First, we need to run the worker.py. Okay, now it connects to the terminal server and start listing on the order queue. And now I will start the order workflow file. So you can see the processing order from a marginal keyboard. Now let's back to the UI. See, you can see the workflow running here. You can click on it to see the scheduling event. And you can see the send confirmation email is failing. Right? Yeah, it is failing and... trying to send it again but what happened if we cancel the worker here I can I cancelled the worker here in the mid process so it's still not completed yet and let me try to restart the workflow again I stopped it because it's to simulate the workflow stacking I restart the worker file here I refresh it Okay, you can see that it picked up every way it left off. No losses, no repeat charts. These are the same confirmation email process and after it completed, it proceeds to the next event. And here is the idea of the label execution in action. Let's back to the slide. So these are not just theoretical benefits. Real companies are using temporal at massive scale. For example, Netflix has the report that Netflix reduced their deployment failure rate from 4% down to 0.0001% using temporal deliverable execution. Teams report 10 times faster development speed because they no longer need to build custom reliability infrastructure. Major companies using it include Netflix. Stripe, Coinbase, NVIDIA, Snap, and HashiCorp. The use case and microservice coordination with SACA patterns, payment processing, CCD pipelines, and one of the hottest areas right now in 2026, AI agent orchestration, where Tempolo provides dual-able execution for multi-agent workflow. Let me wrap up with five key takes away. First, dual-able execution. Your workflow state survives any failure whether it is a server cache, a network timeout, or a service outage. Second, you write normal code, no YAML, no proprietary DSLs, just Python, Go, Java, or TypeScript function, but automatically retires and cache recovery. Configure retry policy per activity and templar handles the list to event history replay. Through observability, the web UI shows you every workflow, every step, every retry. You can debug with confidence. Fifth is a production proven. Netflix, Drive, and Nvidia, or just any company I said before, task it with their most critical system at massive scale. That's for today. If you want to try to help yourself, all the resources are listed here. Thank you for watching if you have any questions. Be free to let me out in the comments.

Learn how Temporal, an open-source workflow orchestration engine, solves the reliability problem in distributed systems with "Durable Execution" — write code as if failures don't exist, and Temporal handles retries, state persistence, and crash recovery automatically.