Runtime Boundaries And Performance
The release runtime cutover adds coordinator-side concepts, but it does not make every execution cross a new network or artifact boundary. The hot path remains transition dispatch through the selected worker.
For the role split behind the terms coordinator, transition worker, and orchestrator-svc, start with Coordinator And Worker Topology.
The durable coordinator is the recovery and operations path, not the lowest-latency path. Low-latency request/response applications should start with SYNC or a local compute deployment and add QUEUE_ASYNC only where durable acceptance, await resume, retry/DLQ, release pinning, or operator recovery is worth the coordination cost.
Runtime Mode Positioning
| Mode | Best fit | Performance posture |
|---|---|---|
SYNC local/compute | low-latency request/response paths | no durable coordinator hop; caller waits for the pipeline result |
One-process QUEUE_ASYNC | local demo and adoption proof | durable runtime semantics are visible, but process-local providers are not HA |
Compute-first QUEUE_ASYNC HA | self-host recovery, await, DLQ/re-drive, release pinning | extra state/queue/worker hops are deliberate durability boundaries |
Current FUNCTION | serverless invocation packaging and adapter semantics | platform invocation availability only; not TPF-owned durable HA |
| Future all-serverless HA | separate design track | likely higher coordination latency because wakeups, queues, timers, and claims are provider events/functions |
The third diagram is future work, not current FUNCTION support. The design spike is All-Serverless Durable Coordinator.
Runtime Mapping
Runtime layout and worker selection stay orthogonal.
| Shape | Worker selection | Intended use |
|---|---|---|
| One-process monolith | no remote worker target, so the local in-process worker is selected | local development, demos, first self-host proof |
| Coordinator + REST/gRPC worker | pipeline.orchestrator.worker.rest.base-url or pipeline.orchestrator.worker.grpc.endpoint configured | production-ish self-host control/data-plane separation |
| Coordinator + SQS worker | pipeline.orchestrator.worker.sqs.request-queue-url configured | brokered worker boundary where request/reply queues fit |
The coordinator does not infer worker selection from pipeline.platform, runtimeLayout, or monolith. A monolith can still run the local worker for batteries-included demos. A separated deployment should configure a remote worker target explicitly.
orchestrator-svc remains a generated module/artifact name in several examples. It can run as the coordinator role, the transition worker role, or both in one local process depending on configuration.
Operators that want to prevent accidental local-worker fallback can enable:
pipeline.orchestrator.control-plane.require-remote-worker=trueWhen the control-plane API is enabled and this flag is true, startup fails unless exactly one REST, gRPC, or SQS worker target is configured.
Patterns In Play
The release runtime uses a small set of explicit patterns:
| Pattern | Runtime role |
|---|---|
| Release registry | stores release records and activation history per tenant and pipeline |
| Activation and pinning | new executions use the active release; existing executions keep their recorded release identity |
| Artifact descriptor | records immutable artifact identity without making the coordinator a deployer |
| Capability gate | verifies the selected worker reports compatible pipeline, contract, release, and optional artifact identity |
| Worker lifecycle gate | verifies a matching lifecycle record is healthy before accepting new hosted executions |
| Control-plane facade | keeps submission, status, await, result, lease, retry, and DLQ ownership on the coordinator side |
| Worker protocol adapter | local, REST, gRPC, and SQS workers execute the same portable transition envelope contract |
pipeline-contract.json plus the active release is the worker compatibility identity. Optional artifact id/digest checks tighten the match when the release descriptor and worker both expose artifact identity.
Performance Posture
The relevant cost boundary is not class count. It is where work runs.
| Path | Work performed | Performance expectation |
|---|---|---|
| Admin registration | parse release descriptor, inspect local/JAR artifact, compute checksum, copy/upload coordinator-managed blobs, record immutable external artifact references | off hot path; can perform blocking file/network work |
| Activation | append activation metadata and validate stored artifact identity | operator path; not per transition |
| Hosted submit | read active release, verify stored artifact metadata, check worker capability and lifecycle, create execution | one-time admission cost per execution |
| Transition dispatch | claim lease, build pinned transition envelope, invoke selected worker, commit outcome | hot path; must not hash artifacts or scan registries |
| Await resume | use release identity pinned on the execution record | hot path; independent of the currently active release |
Guardrail: artifact hashing and full registry scans must stay out of transition execution. Transition envelopes carry recorded identity; they do not re-validate the release descriptor on every step.
The current submit path does availability and lifecycle checks before accepting hosted work. That is intentional admission work. If this becomes too expensive, the next optimization is caching worker capabilities and lifecycle views with a short TTL, not moving validation into transitions.
Package Boundaries
The runtime package is split by responsibility:
| Package | Responsibility |
|---|---|
org.pipelineframework.orchestrator | execution records, stores, queue-async coordinator, transition envelopes, protocol clients, and existing config |
org.pipelineframework.orchestrator.release | contract/release descriptors, release registry, release registrar, and release admin resource |
org.pipelineframework.orchestrator.worker | worker capability, availability, and lifecycle checks |
This split is intentionally bounded. It does not move the transition worker protocols or durable execution records because those remain core queue-async runtime concerns.
Current Limits
- The one-process monolith remains valid for local/dev proof, not as the recommended separated deployment.
- Worker lifecycle is a minimal submit-admission gate, not fleet routing or autoscaling.
- File-backed release registry is still local/single-coordinator oriented; Dynamo release metadata is the HA path.
- Local release artifact storage is still local/single-coordinator oriented; S3-compatible release artifact storage is the multi-coordinator path only for blob artifacts that the coordinator manages directly.
- Runtime worker-reported artifact digest drift remains a follow-up; current capability checks cover pipeline, contract, release, and configured artifact identity.