DEV Community: Omkar Dusane

Durable Workflows Hiding in Plain Sight

Omkar Dusane — Fri, 02 Oct 2026 20:35:17 +0000

In my last post, I walked through one problem where durable execution fit naturally. This time I want to zoom out. Some of the best candidates for this pattern aren't exotic. They're sitting in products we use every day, and most teams build them the traditional way without a second thought.

One note: these are my own sketches of how such systems could be modeled, not how any of these companies actually build them. The code is pseudocode, not production code.

The Pattern We Keep Missing

When we build a feature, we usually follow the flow of what the system already has: a Kafka topic here, a status column there, a cron job somewhere else. Over time, code for orchestration and business code get fused together. Retries, acknowledgements, timers and state sync end up tangled with the actual product rules.

A fresh look at these use cases lets us spot the workflow shape early, in the initial version of a product. Then the separation isn't only about infrastructure. Whole behavioral patterns can be pulled out of the backend and treated as one unit.

Use Case 1: The Booking That Lives for Weeks (Airbnb-style)

A traveler confirms a booking, and from that moment a reservation state machine starts:

Payment: the account is debited on a set day after confirmation.
Refund window: fully refundable until 48 hours before check-in. After that, cancellation is still possible, but only for the remaining nights.
Policy varies per listing, so the rules aren't global.
Human in the loop: a cancellation on the day of arrival needs a decision from the host or traveler. We want humans involved only for that decision, nothing else.

async function reservationWorkflow(booking, policy) {
  let cancel = null;
  onSignal('cancelRequested', (req) => { cancel = req; });

  await sleepUntil(policy.debitDate);
  await chargeGuest(booking);

  await sleepUntil(booking.checkIn - hours(48)); // free-cancel window closes
  // ...partial refund rules apply from here

  if (cancel && isArrivalDay(cancel)) {
    const decision = await waitForSignal('hostDecision'); // human step
    await applyResolution(booking, decision);
  }
}

The timeline of the booking is the code. Humans only show up where judgment is needed.

Use Case 2: The Order and Its Journey (E-commerce)

This one is everywhere. A delivery partner like DHL sends webhooks about a package's status. The usual approach:

The webhook lands on a Kafka topic.
One service picks it up, processes it, and produces a follow-up event.
Another service picks that up, decides whether this user even wants this notification ("out for delivery" yes, "arrived at intermediate hub" probably not), and sends it.
Retries, acknowledgement checks and dedupe are scattered across all of it.

Business rules and orchestration end up in the same handlers. Changing "who gets which notification" means touching retry logic too.

Now flip the view. The order is an entity, and there's one long-running workflow on it, from the seller's warehouse to the customer's door:

async function orderJourneyWorkflow(orderId, prefs) {
  let state = await initialState(orderId);

  onSignal('carrierUpdate', async (update) => {
    state = applyUpdate(state, update);
    if (prefs.wants(update.level)) {
      await notifyUser(orderId, update);
    }
  });

  await waitUntil(() => state.delivered || state.cancelled);
}

All the handlers live in one place, and they read like plain API calls instead of "Kafka subscribe, Kafka publish, blah blah."

looks like a React Component?

This is the mental model that clicked for me. A React component lives for maybe two minutes while a user interacts with it. It holds state, has handlers for events, and each handler says how state changes.

A durable workflow is the same shape, but the "session" stretches over days or weeks, and the "clicks" come from carriers, hosts, timers or other services. The business logic is only this: given the current state and this interaction, what's the new state? Persisting state, queuing events and waking up at the right time are abstracted away.

Bonus: Shared Work, Done Once

Not every workflow is per-user or per-order. Take a streaming home screen: "Top 10 in your region" depends on the segment a user belongs to, not the user. There are far fewer segments than users, so for each segment and each interval you want to compute once and serve thousands. A small workflow per segment (gather, rank, publish, sleep until the next interval) keeps that calculation from running thousands of times, with durable state if it fails halfway. Fair warning: the heavy compute lives elsewhere, so the win here is orchestration, not the ranking itself.

Does It Have to Be Temporal?

No. You could build this yourself with a persistence layer for state and a queue for events. Temporal is one way, and there are others emerging. The tool matters less than the realization: software keeps getting more complex, and we keep working on smaller pieces of bigger systems. That's a good moment to pull complete packages of functionality into one place where they're maintainable, and to solve their shared problem (orchestration) once, together. Consistency is a bonus.

Cheers!!

Demystifying Durable Workflows: A use case from Uber

Omkar Dusane — Wed, 30 Sep 2026 15:39:31 +0000

In my last post, I introduced Durable Execution (or "Code-First Workflows") as a fast-emerging architectural primitive. A paradigm only really clicks when you watch it solve a messy, real problem, so let's look at one.

Back in 2018-19, a friend at Uber walked me through how they handled ride-end payment notifications in India. It ran on Cadence, the engine that Temporal later grew out of, built by the same people. Below is the problem, and how I'd model it with Temporal today.

One note: this is my understanding from that conversation, and the code is a simplified sketch, not production code from Uber.

The Product Challenge: Cash vs. Digital

Cash was still heavily used for ridesharing in India back then, and it created real friction at the end of a trip:

The double-pay confusion. A rider picks Digital (UPI, credit card, Paytm), but the driver asks for cash anyway, out of habit or confusion. The app needed to say it plainly: "Digital payment selected. Do NOT pay cash to the driver."
The default payment trap. Riders carried over a last-used method, often Cash, and only realized near the end of the trip that they had no cash on them.
No post-ride switching. Changing the payment method after the ride ended hadn't shipped yet, so a trip that ended on Cash left rider and driver in an awkward standoff. ## The Requirement

To give riders one last window to switch payment methods before the ride locked, product wanted a notification with three rules:

Timing: send it 5 minutes before the ride ends.
Cap: at most 3 notifications per ride.
Moving target: the ETA keeps changing with traffic, so "5 minutes before the end" is never a fixed timestamp. Sending a notification is trivial. Sending it at the right moment, the right number of times, on a trip whose end time keeps shifting, is the actual problem.

Option A: Build It Yourself

With traditional building blocks (DB status flags, SQS delay queues, Redis TTL keys, cron scripts), this is possible, but painful for what it delivers. You end up writing a bespoke distributed state machine just to manage time-based logic. The glue code you own looks like this:

Timer engine. Thousands of ephemeral delayed jobs in SQS or RabbitMQ, or a polling mechanism, just to track "5 minutes before the end" while ETAs keep shifting with traffic.
Locking and state sync. Guarding against double notifications when an ETA update and a timer expiry hit two different workers at once, and keeping a Redis counter for the 3-notification cap in sync with the ride lifecycle across services.
Cleanup. Purging or skipping scheduled messages when a ride cancels, ends abruptly, or completes early. Most of your code ends up being plumbing (retries, locks, timer offsets, state cleanup) rather than the product logic of sending one notification. You've built a fragile, miniature workflow engine inside your own application.

Option B: Durable Execution

With a code-first workflow engine like Temporal, you don't build a state machine out of tables and timers. Your code IS the state machine.

Temporal gives you durable timers and signals. You write a plain loop with a sleep in it, and signals feed in ETA updates and ride-end events. If the worker running it dies, the cluster restores the exact loop state, timer, and variables and carries on as if nothing happened.

Here's a simplified sketch of how this could look in Temporal (pseudocode, not production code):

async function rideEndNotificationWorkflow(rideId: string) {
  let eta = await getInitialEta(rideId);
  let rideActive = true;
  let sent = 0;

  onSignal('etaUpdated', (newEta) => { eta = newEta; });
  onSignal('rideEnded', () => { rideActive = false; }); // ended or cancelled

  while (rideActive && sent < 3) {
    const waitTime = eta - now() - minutes(5);

    if (waitTime > 0) {
      // durable timer: wakes early if a signal arrives
      await sleepOrSignal(waitTime);
      continue; // re-check: ETA may have changed, or the ride may be over
    }

    await sendPaymentReminder(rideId);
    sent++;
    await sleepOrSignal(minutes(1)); // brief pause before any re-send
  }
}

Read it top to bottom and it's just the business rule: wait until 5 minutes before the end, notify, stop after 3 or when the ride is over.

Why This Wins

No external state. No Redis counter, no delay queues, no status flags. The counter and the timer live in the workflow itself, so there's nothing to keep in sync.
Cancellation and cleanup come almost free. When the ride ends or cancels, the signal flips a flag and the loop exits. There are no orphaned delayed messages to hunt down.
The code reads like the business rule. Product can look at that loop and recognize their own spec. That's a big deal for maintenance. None of this is free, and I'll cover where it bites in the next post.

In the next one, I'll get into why some engineering organizations evaluated Temporal and walked away, and how those evaluations played out.

Cheers!!

Spotting an architectural paradigm Pioneered by Temporal - Durable workflows

Omkar Dusane — Mon, 28 Sep 2026 15:03:26 +0000

I have been noticing something manifesting a massive architectural emergence in software engineering called Durable Execution (or "Code-First Workflows"). It started gaining traction in 2018-19 when I was looking for a declarative workflow writing framework and landed on Apache Cadence, by Maxim Fateev being used at Uber. Talked to Maxim back then and realized I would have to build a full Node.js SDK from scratch to use it, so I took a different path, but kept checking on it. When Uber split Cadence into open-source (similar to how Kafka detached from LinkedIn), I was fascinated by the architecture and kept finding new use cases. By 2022, I was evaluating and adopting Temporal for real production-scale projects, and I personally enjoyed modeling payment and invoicing workflows with it. Recently through 2024 to early 2026, I have been seeing another major use case emerge around evaluation loops and agentic execution. Modeling long-running tasks into discrete pieces remains a fascinating challenge, and how you approach that modeling is the key differentiator between shooting yourself in the foot or seeing immense simplification and benefits.

I will cover why certain engineering organizations rejected Temporal and how those evaluations played out in a separate post. For now, the core takeaway is clear: durable execution has officially crossed over from specialized infrastructure into a standard developer primitive.

This evolution reminds me a lot of how Apache Kafka transformed data pipelines. Just as Kafka became the undisputed open-source standard for event streaming after leaving LinkedIn, I am watching closely to see if Temporal achieves that similar ubiquitous, foundational fate for orchestration. Modern serverless platforms like Inngest are pushing this paradigm even further into everyday web applications, but at its core, the heavy lifting of durable state management traces right back to this fundamental engine.

Whether Temporal becomes the industry-wide default or remains part of a broader ecosystem alongside lighter abstractions, durable execution is here to stay. In upcoming posts, I will dive into real-world production use cases and practical workflow modeling from architecting payment engines to designing resilient AI evaluation loops.

Cheers!!