Articles
Durable Functions Interview Questions: Replay, Orchestrator Determinism, and External Events
Practice Durable Functions interview questions on replay, deterministic orchestrators, activity side effects, external events, timers, and version-safe changes.
Your order-approval workflow logs “reserve stock” three times. Did it reserve stock three times, or did the orchestrator replay the same control flow while reading its execution history? In a Durable Functions interview, treating those as equivalent can lead to the wrong repair—and to duplicate side effects.
These Durable Functions interview questions use one order workflow to explain replay, orchestrator determinism, external events, and safe changes to long-running instances. Practice debugging a concurrent job scheduler as a related state-transition exercise, then apply the Durable Functions history model below.
Evidence boundary: Microsoft documentation establishes the replay, code-constraint, timer, event, and versioning behavior discussed here. The order numbers, decision tables, and interview scenarios are original exercises. Language APIs and hosting/storage choices vary; the article does not claim a universal employer interview format.
The short answer: replay control flow, not business truth
A Durable Functions orchestrator defines a workflow, schedules activities and timers, and waits for events. The runtime persists an execution history. When an instance wakes after more input, it can rerun orchestrator code from the beginning and replay completed work from history to reconstruct local state. That is why the orchestrator must make the same scheduling decisions when replaying the same recorded inputs.
This is not the same as running every activity again just because the orchestrator's code body executes again. A completed activity result in history can be supplied to replayed control flow. But an activity can still be attempted more than once under failure conditions, so a payment or shipment activity needs its own idempotency and reconciliation contract. Deterministic orchestration protects history compatibility; idempotent activities protect external effects.
A strong interview answer identifies the boundary under discussion. If duplicate logs come from a replayed orchestrator statement, use replay-safe logging rather than deduplicating shipments. If the external service saw two requests, inspect activity attempts, operation IDs, and downstream responses. The same visual symptom can have two very different causes.
Why must an orchestrator be deterministic?
On replay, the runtime expects the orchestrator to schedule compatible work in an order consistent with its history. Directly reading wall-clock time, generating an ordinary random value, performing network I/O, or depending on mutable static or environment state can produce a different branch. A deployment that reorders activity calls can do the same for in-flight instances even if each individual line of code looks deterministic.
Use APIs supplied by the orchestration context for time and supported deterministic identifiers, and move external I/O into activities. Pass changing configuration as stable orchestration input or record it through an activity result. Be careful with helper functions: hiding a database query inside a “pure-looking” helper does not make it safe during orchestrator replay.
The requirement is not “the same final answer eventually.” Replay must be able to reconstruct the same sequence of durable decisions. If history says ReserveStock was scheduled and the new code schedules CancelOrder at that position, the runtime cannot simply pretend they match. The safest code review question is: given the same recorded input and history, will this version request the same next durable action?
| Code inside orchestrator | Replay risk | Better boundary |
|---|---|---|
| Read the system clock to choose a branch | Time changes between executions | Orchestration-context time |
| Call a payment or HTTP API directly | Call can repeat during replay | Activity with stable operation ID |
| Generate a normal random identifier | Different value can change history | Supported deterministic context API or input |
| Read mutable deployment settings mid-run | Existing instance can take new branch | Versioned input or recorded activity result |
Do not oversimplify to “orchestrators cannot do any calculation.” Pure arithmetic and stable decisions based on recorded input and results are exactly what orchestrators are for. The constraint is about unrecorded variability and side effects.
Trace a mismatch after a deployment
Imagine version 1 of an order orchestrator schedules ReserveStock, waits for external Approval, then schedules FinalizeOrder. An instance starts on Monday and reaches the wait. The history now contains the ReserveStock schedule and result plus the wait decision.
On Tuesday, version 2 is deployed. A developer adds a check using the process clock: “if current time is past the order deadline, schedule CancelOrder before waiting.” The existing instance wakes because an approval event arrives. During replay, it now takes the Tuesday branch and requests CancelOrder where its recorded history expects the previous path. The problem is not merely that the order is old. It is that code for an in-flight instance made a different durable scheduling decision from its own history.
There are two repairs to distinguish. For a new workflow, use orchestration-context time and a durable timer to express the deadline. For existing instances, preserve their compatible code path through orchestration versioning or a side-by-side deployment strategy. Simply swapping the wall-clock call for a context API in version 2 may not fix a changed scheduling order already incompatible with version 1 history.
In the interview, write a three-column trace: history expected, current code requests, and observed status. If you cannot name the first divergence, you are guessing. Check the instance ID, function version, history, and recent deployment before restarting anything. Terminating every in-flight instance is a data-loss decision, not a routine debugging shortcut.
Where should side effects happen?
Activities are the boundary for network calls, database writes, emails, inventory reservation, and other external work. The orchestrator can schedule an activity and branch on its recorded result. The activity itself must tolerate retry or ambiguous completion if the runtime fails after the external effect but before recording completion.
For ReserveStock, give the business operation an idempotency key such as order ID plus operation type. The inventory service should return the same reservation outcome for a repeated key, or the activity should query and reconcile the previous result. If the inventory API has no deduplication or lookup support, explain the residual risk and a human repair process. Durable orchestration does not make two independent systems commit atomically.
Suppose an activity reserved stock and the worker crashed before its completion reached durable history. A new attempt may call the inventory service again. That is an activity ambiguity, not an orchestrator replay duplicate. Conversely, if the history already includes the result, replay can supply it without reissuing the activity. Interviewers often test this precise distinction.
Keep payloads small and stable. A history full of large mutable business objects makes replay and versioning harder. Store large data externally and pass a durable reference and version where appropriate, with an activity retrieving it. Then state how you handle the object changing or disappearing between activity attempts.
How should an approval external event be modeled?
An external event targets an orchestration instance by instance ID and event name and carries serializable data. The name must match the event the orchestrator waits for. If an event is sent to the wrong instance ID, or no matching instance exists, the intended workflow may never observe it. The sender should not assume an HTTP acceptance alone proves that the business approval was applied.
Microsoft documentation warns that external events can be delivered more than once under failure conditions. Put a stable approval event ID in the payload and define duplicate behavior. An approval state transition can record that ID and reject or ignore a repeat. Check who is allowed to send the event and whether the approver is authorized for this order; an event payload is not proof of business authority.
What if the approval arrives before the orchestrator reaches the wait? The runtime can queue a matching event for a running instance, but the candidate should still reason about instance creation, event names, delivery guarantees, and any deployment race. Define the source-of-truth decision in durable business state if the workflow's side effects matter beyond the orchestration instance.
For a rejection event, avoid overloading “Approval=false” if separate names make the decision clearer. Whether you use one typed event or multiple names, document the valid state transitions and handle duplicate or contradictory callbacks. An approval arriving after cancellation should not reopen an order accidentally.
How does a durable timeout race with an event?
Use a durable timer rather than a language-native sleep. Calculate its deadline from orchestration-context time so replay makes the same choice. Schedule the approval wait and the timer, then handle whichever durable task completes according to the language SDK's supported pattern. If approval wins, cancel the outstanding timer when required by that pattern. If the timer wins, record timeout and choose the appropriate cancellation or escalation activity.
Near the deadline, “which happened first?” needs a precise business rule. Event ingestion time, orchestration processing order, and human action time can differ. A clock screenshot from an approver is not enough. Define whether an approval submitted by the deadline but processed later counts, and keep the evidence needed to enforce that rule. The orchestration implements the policy; it does not invent it.
After timeout, an external callback might still arrive. Decide whether to ignore it, record it for audit, or launch a separate appeal. Do not let the same order be both finalized and canceled. Use a durable order state or idempotent transition so that even an activity retry cannot create contradictory business outcomes.
A useful test matrix includes approval well before deadline, timeout without event, event near deadline, duplicate event, wrong instance ID, worker restart during wait, and deployment while waiting. The purpose is to predict durable state and external effects in each case, not merely to assert that the orchestrator “resumes.”
What changes safely for long-running instances?
Durable Functions instances can live beyond a single deployment. Renaming an activity, changing input shape, adding or reordering durable calls, or removing a branch can break replay against old histories. Treat workflow definitions as versioned interfaces. A code review should ask how many in-flight instances exist, what history they have already recorded, and which worker version will process them.
Microsoft documents orchestration versioning as a way to isolate compatible code paths; side-by-side applications or task hubs are other strategies when isolation needs differ. The specific feature support depends on installed extension and hosting choices. Do not assert that a version flag automatically makes an arbitrary incompatible edit safe. Keep the old path available long enough for old instances to finish or be deliberately migrated.
When a deployment causes nondeterminism, first stop increasing damage, preserve instance IDs and diagnostics, and identify the first incompatible history event. Roll back or route affected versions to compatible code. Then plan any migration explicitly. Replaying or restarting an orchestration with a new instance ID may reissue business work, so reconcile activities before attempting it.
A concise answer to give
“Durable Functions may replay orchestrator code from history to reconstruct state, so the orchestrator must make deterministic scheduling decisions. I would use context time and supported deterministic APIs, keep external I/O in activities, and make those activities idempotent because an activity can be retried after an ambiguous completion. Approval events need the right instance ID and event name plus a stable event identity; a deadline should be a durable timer. For an incompatible deployment, I would preserve old instances on compatible versioned code, inspect the first history mismatch, and reconcile business effects before any restart.”
Practice that answer by changing the crash point. A correct explanation of replay is only the first half; the second is proving whether the actual order, inventory, or payment state is safe.
Sources and Further Reading
- Microsoft: Durable orchestrations
- Microsoft: Orchestrator code constraints
- Microsoft: External events
- Microsoft: Durable timers
- Microsoft: Versioning in Durable Functions
- Microsoft: Diagnostics and replay-safe logging
Research checked September 21, 2026. Confirm the SDK, extension version, and storage provider in your target deployment before relying on a particular API or versioning feature.