Runtime Topology Strategy

This guide is for software architects choosing how a pipeline is deployed.

Decision model

Choose topology by balancing:

• Change isolation (blast radius)
• Operational footprint (containers/charts)
• Latency budget (network hops vs in-process calls)
• Security boundaries (public ingress and service exposure)
• Team ownership boundaries

Topology trade-offs

Topology	Strengths	Risks
modular	Strong isolation, clear ownership, independent scaling	Highest operational overhead
pipeline-runtime	Good compromise: isolated orchestrator + grouped service runtime	Some coupling inside grouped runtime
monolith	Lowest deploy complexity and network latency between steps	Largest blast radius and least isolation

Orchestrator boundary

Keeping the orchestrator isolated is usually a good default when you want:

• One external ingress point
• Reduced attack surface for internal services/plugins
• Stable migration path from grouped runtime to more modular layouts

Current topologies still assume the generated application owns and runs the orchestrator host. For the internal target architecture that separates app/data-plane workers from a durable control plane, see Durable Coordinator.

Plugin/synthetic placement

Treat plugin side effects as first-class when designing topology. They are easy to forget and can silently add coupling or load to the wrong runtime.

Practical rule:

• If plugins are operationally independent concerns (persistence/cache/observability), keep their placement explicit in runtime mapping.
• In monolith mode, accept that plugins collapse into the same blast radius as core steps.

Migration architecture

Recommended evolution path:

1. pipeline-runtime as default operational baseline.
2. Split hotspots from grouped runtime into dedicated modules/runtimes when needed.
3. Keep runtime mapping and Maven topology synchronized at each step.

This avoids "logical layout only" drift where YAML says one thing but build artifacts enforce another.