Most API calls complete in seconds. The harder question is what happens when the work they trigger takes hours or days. Consider an insurance claim submitted from a phone in two seconds. Assessing damage, checking policy limits, running fraud checks, involving an adjuster, and paying the claim can take far longer. The Claims API can return 202 Accepted immediately, but that response only acknowledges receipt. It does not complete the business promise.
This blog uses the insurance claims journey as its running example, following claim 98371 from submission through assessment, settlement, and payment confirmation. The client sees a quick call and a tracking ID. Behind it, services must parse documents, run AI models, check fraud, wait for a human decision, calculate the payout, and wait for bank confirmation. Once the HTTP lifecycle ends, a connection or thread cannot carry that obligation. The process needs durable state, explicit contracts, and an intentional recovery model.
Why long-running processes need workflows
A single service can handle a short request-response interaction. It is the wrong unit of coordination when the work crosses multiple services, people, events, and long waits. The claims API should return quickly with a claim ID and an operation or status location. A durable workflow then carries the business obligation forward.
Services still own business capabilities: validation, document analysis, fraud detection, and payments. The workflow owns sequencing, persisted execution state, waits, retries, timeouts, and recovery policy. For claim 98371, it can record that payment was initiated and wait for confirmation; it does not need to keep an HTTP connection or application thread open. If a worker restarts or a deployment occurs, execution can resume from the recorded state rather than replaying the entire claim.
The insurance claims architecture
The architecture deliberately separates assessment from settlement at a meaningful business fact. Assessment decides and records whether the claim is approved. Settlement creates and verifies the payment. They have different owners, failure modes, and release cadences, so they should not share one execution lifecycle.
POST /claims -> 202 Accepted + claimId + operationId
-> Claim Assessment Workflow
validate -> AI analysis -> fraud check -> human review (when required)
-> persist approval -> TxEventQ: claim.approved
-> Event Handler -> Claim Settlement Workflow
create settlement -> initiate payment -> wait for confirmation
-> update claim -> TxEventQ: claim.settled
In MicroTx Workflows, the assessment workflow can use HTTP, SQL, agentic, human, and wait tasks as appropriate. After approval is durably recorded, a TX EventQ Publish task publishes claim.approved to a TxEventQ topic. An event handler filters the event and starts the settlement workflow with mapped input and the same correlation ID. The producer knows the fact that happened; it does not need to know every consumer that will act on it.
Treat the event as an asynchronous API. Name it for the business fact, version its schema, and include the identities that make repetition and investigation safe.
{
"eventType": "claim.approved",
"eventVersion": "1.0",
"eventId": "evt-98431",
"correlationId": "claim-98371",
"causationId": "evt-98122",
"data": {"claimId": "98371", "approvedAmount": 12500}
}The eventId identifies one immutable event for deduplication. The correlationId follows the claim across APIs, events, and workflows. The causationId identifies the direct trigger. Together, these identifiers give operators the context they need when a customer asks, “Where is my claim?”
Why this methodology is a stronger fit
A synchronous API chain is still the simplest choice for short, atomic work. It becomes fragile when a business outcome depends on several services, human decisions, long waits, and external systems whose outcome may be uncertain. Many existing designs add a queue to decouple services, but a queue alone moves messages; it does not own the business process, its state, its deadlines, or its recovery decisions. Other teams build custom saga or orchestration code, which can work but often recreates retries, duplicate protection, compensation, and operational visibility differently for every process.
MicroTx Workflows and TxEventQ provide a more complete methodology for this class of problem. The workflow durably coordinates the journey and records its state. TxEventQ carries a versioned business fact across a clean ownership boundary. Services continue to own their business capabilities rather than being absorbed into one central application. The result is not a claim of magical exactly-once execution; it is a design that assumes retries and uncertainty, then makes repeat execution safe and explainable.
- Compared with synchronous API chaining, it avoids holding a request, thread, or connection open while the business process waits.
- Unlike queue-based integration alone, this approach provides durable coordination for sequencing, timeouts, human approvals, and business status. Compensation is explicit application logic, not an automatic XA rollback of external effects.
- Compared with custom-built orchestration, this approach applies repeatable controls for idempotency, retries, deadlines, correlation, and recovery instead of leaving every team to rebuild them.
Make the architecture fail safe
Distributed systems do not provide perfect knowledge at every boundary. A timeout does not prove that work did not start; a redelivered event does not mean the first delivery failed; a lost payment reply does not prove the payment failed. Design for at-least-once delivery, then make repeated execution safe. Here are some common failure scenarios.
Failure 1: the client loses the response
The Claims API starts the assessment workflow, but its response is lost. The client retries POST /claims because it cannot know whether claim 98371 was accepted. Without a stable identity, the retry could start a second assessment and produce a second claim decision.
Control to handle this failure: require an Idempotency-Key that represents the logical submission, such as claim-request-98371. Persist the mapping from client key to claim and workflow execution. Reuse that key when starting the workflow so the API can resolve the retry to the same logical operation and return the same status rather than starting duplicate work.
Failure 2: claim.approved event arrives twice
A publisher retry, broker redelivery, consumer restart, or lost acknowledgement can deliver event evt-98431 more than once. If every duplicate delivery triggers settlement and payment, a routine messaging retry can become an incorrect financial transaction.
Controls to handle this failure: Deduplicate inbound events by eventId and use workflow start idempotency so the event handler cannot create duplicate settlement executions. Enable task level idempotency for supported tasks, including the TxEventQ Publish task in MicroTx. Custom workers and external side effects still require idempotency in the worker or downstream service, for example by passing claim-98371:settlement to the payment service as a business key. This layered approach is more reliable than relying on a single promise of “exactly once” processing.
Failure 3: payment succeeds, then the reply is lost
The settlement workflow authorizes $12,500, the payment service succeeds, and the network loses the reply. The workflow now has an unknown outcome. Blindly retrying could pay for the claim twice; treating the timeout as a failure could leave a completed payment unrecorded.
Controls to handle this failure: separate the timeout for one call from the retry budget and the business deadline for an unresolved settlement. Retry transient errors only with the same payment idempotency key, or query the payment state before acting again. When the outcome cannot be established safely, route the claim to an explicit exception path: compensation when appropriate, investigation, or human review. Compensation is a new idempotent business action, not an assumption that distributed rollback will fix everything.
Operate confidently in production
Production confidence comes from being able to locate, explain, and safely recover one business journey. Build a claim timeline that connects submission, assessment workflow, AI result, human decision, claim.approved, settlement workflow, payment attempts, and claim.settled. Carry claimId, correlationId, workflow IDs, event IDs, and downstream payment IDs through workflow input, event headers, logs, and traces.
- Expose business state: report SUBMITTED, UNDER_REVIEW, APPROVED, SETTLING, SETTLED, or an explicit exception state instead of internal task names.
- Alert on outcomes that need action: workflow deadline breaches, repeated task failures, growing event backlog, duplicate-event rates, and payments that remain unknown beyond the business deadline.
- Prepare recovery runbooks: identify the completed steps, retrieve the downstream payment status, decide whether retry, compensation, or human escalation is safe, and record the operator action against the same correlation ID.
Handle AI inside a deterministic reliability envelope
In the assessment workflow, AI can extract facts, classify damage, and recommend a route, but its output remains untrusted input. For claim 98371, validate the structured result and confidence bounds, persist the evidence and decision context, then let deterministic policy decide whether to auto-approve, route to an adjuster, or reject the result. Keep irreversible actions, especially payments, behind deterministic workflow controls.
Implementation blueprint
Here is an implementation blueprint for applying this approach to a long-running, event-driven business process.
- Accept POST /claims, capture the logical idempotency key, return 202 with claimId and operationId, and expose business status.
- Start Claim Assessment Workflow to validate, analyze, check fraud, and await human approval when policy requires. Persist approval before emitting the event.
- Publish versioned claim.approved through a Tx EventQ Publish task with eventId, correlationId, causationId, occurrence time, and required business data.
- Configure a TxEventQ event handler to filter and deduplicate claim.approved, map the input, and start Claim Settlement Workflow with a workflow-start idempotency key.
- In settlement, persist the ledger record, call payment with the business idempotency key, await confirmation or the business deadline, then update the claim and publish claim.settled.
- Apply retry budgets, timeouts, compensation or escalation, correlation, dashboards, and operator runbooks before treating the flow as production-ready.
Summary
A 202 response starts a durable obligation. For the insurance claim, MicroTx Workflows carries the work across services, AI, people, waits, and recovery. TxEventQ lets assessment and settlement evolve independently. Layered idempotency, bounded retries, explicit recovery, and end-to-end correlation make the architecture safe to operate. Try the sample implementation here.