PATTERN Cited by 1 source

Coordinator-worker split

A distributed systems pattern where a long-running orchestration task is split between a coordinator (single leader, owns global lifecycle) and workers (one per partition/shard, do local data work). Communication typically flows downward through shared metadata (cluster state, ZooKeeper, etcd) and upward through direct RPC or transport actions.

Structure

Coordinator (leader node)
├── Tracks global phase (initializing → backfilling → converging → cutting over)
├── Makes global decisions (when to write-block, when to swap)
└── Listens for worker progress reports

Workers (data nodes, one per shard/partition)
├── Do local computation (backfill, replay, compaction)
├── Report progress + transitions to coordinator
└── React to phase changes published by coordinator

Why Not External Orchestration?

In AOSC's case, the primitives needed (Engine.Searcher, changes snapshot, retention leases) are shard-local — only accessible on the node hosting that shard's primary. Streaming data externally would be slow and fragile. Running the work in-cluster, colocated with shards, avoids network serialization of the full dataset.

Seen In

• systems/opensearch-aosc — AoscCoordinatorService (cluster-manager) + AoscShardService (data nodes) pattern
• sources/2026-07-24-atlassian-online-index-migration-and-shard-scaling-in-opensearch-with-aosc

(Source: sources/2026-07-24-atlassian-online-index-migration-and-shard-scaling-in-opensearch-with-aosc)