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 and Infographic
This pipeline is a textbook fan-out/fan-in — spread 8 independent lanes of work in parallel (fan-out), wait at a barrier until all 8 are done (fan-in), then continue sequentially. Sequential execution takes 8x longer for no reason. Skipping the barrier violates the dependency. Fan-out/fan-in is the exact pattern built for 'do N things in parallel, then combine when all finish.'
Full explanation below image
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 (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. Orchestrator fans out to 8 agents simultaneously (each receives its service assignment) 2. Orchestrator holds a barrier counter: when each agent reports completion, the counter increments 3. When counter reaches 8, the barrier releases and step 3 begins with all 8 image references 4. Step 3 produces the manifest; step 4 deploys it
Option A (sequential per service) is correct for dependency ordering but wastes parallel capacity — 8x slower for steps 1-2. Option C (event-driven) 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. Option D (hierarchical per-service sub-orchestrators) 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.