Operational Confidence

The Pipeline Framework (TPF) is designed for production environments where teams need retries, crash recovery, failed-work handling, and runtime health to stay understandable.

At a Glance

Container Ready · Fits naturally into container and Kubernetes deployment models.

Runtime Visibility · Generated endpoints, status data, and telemetry make it easier to see what is running and how work moves.

Crash Survival · For persistence-backed background execution such as `QUEUE_ASYNC`: accepted work can be stored outside the JVM, retried, recovered, and investigated.

Use This When

• Production incidents take too long to diagnose.
• Teams need a consistent operational baseline across services.
• Container/Kubernetes rollout has outpaced ops maturity.

For background execution, TPF can record accepted work outside the current process before it depends on that work being complete. If the JVM, container, or worker dies, another worker can pick up the stored execution and run it again after the lease expires. This is lease-based recovery, not mid-pipeline checkpoint resume, so teams should design downstream calls and writes to be safe when the same work is attempted again.

The exact TPF mode for this is QUEUE_ASYNC. In plain terms, this is the background execution mode where TPF stores execution state, dispatches work, retries failed transitions, recovers leased work after crashes, and can publish terminal failures to a DLQ, a dead-letter channel for investigation or replay.

Persistence and caching strengthen this recovery story. Persistence gives teams durable business records they can inspect or query after a failure. Cache reduces the cost of replaying expensive downstream work when recovery requires recomputation instead of a full rerun.

Jump to Guides

• Error Handling & DLQ
• In-flight Probe
• Orchestrator Runtime
• State, Replay, and Queryable Data
• Observability
• Best Practices