A platform team is automating a software release pipeline: (1) run unit tests for 8 independent microservices, (2) build container images for each passing service, (3) generate a combined release manifest once ALL images are built, and (4) deploy the manifest to staging. Steps 1-2 are independent per service but step 3 has a hard join dependency on all 8 step-2 outputs. Which orchestration pattern BEST reflects this dependency structure?
Select an answer to reveal the explanation.
Short Explanation
This pipeline is a textbook fan-out/fan-in: you spread 8 independent lanes of work in parallel, wait at a barrier until all 8 finish, then continue sequentially. The sequential per-service approach wastes parallel capacity, and skipping the barrier violates the hard join dependency. Fan-out/fan-in is the exact pattern built for doing many independent things in parallel, then combining when all finish.
Full Explanation
Orchestration pattern selection must follow the actual dependency graph, not a preference for simplicity or maximum parallelism.
Steps 1-2 per service: each service's tests and image build are completely independent of every other service. They share no state, read no shared files, and produce no outputs that other services in the same phase need. This is a fan-out opportunity; 8 parallel lanes maximize throughput.
Step 3, the release manifest: has a hard join dependency on all 8 image build outputs. It cannot proceed until the last image is available. This is the fan-in point, a barrier synchronization where the orchestrator waits for all parallel branches to complete before proceeding.
Step 4, staging deployment: sequential dependency on step 3 only. After step 3 produces the manifest, step 4 follows immediately.
Fan-out/fan-in implementation: 1. The orchestrator fans out to 8 agents simultaneously, and each agent receives its service assignment. 2. The orchestrator holds a barrier counter; when each agent reports completion, the counter increments. 3. When the counter reaches 8, the barrier releases and step 3 begins with all 8 image references. 4. Step 3 produces the manifest, and step 4 deploys it.
The sequential orchestration that completes all pipeline steps for service 1, then service 2, and so on through all 8 services preserves dependency ordering but wastes parallel capacity, making steps 1-2 about 8 times slower. The event-driven orchestration where each step publishes a completion event and the next step subscribes dynamically, without a central coordinator tracking step completion, has a barrier problem: without a central coordinator, how does step 3 know all 8 events have arrived? Distributed fan-in tracking without a coordinator introduces significant complexity and race condition risk. The hierarchical orchestration where a top-level orchestrator delegates all 4 steps to per-service sub-orchestrators that run their steps sequentially runs each service's steps sequentially within the sub-orchestrator and would still need a top-level barrier for step 3; it adds overhead without addressing the dependency structure.