Skip to content

PATTERN Cited by 1 source

Coordination-execution separation

Intent

Separate the coordination layer (request validation, work composition, caching, deduplication, dispatch) from the execution layer (the actual computation or transformation) so they can scale, fail, and evolve independently.

Problem

When coordination logic (routing, caching, retry, dedup) is embedded in the same service as execution logic, you get: - Coupling between request-handling scale and compute scale - Duplicate cross-cutting concerns across execution backends - No single point to add caching or deduplication - Each backend must independently handle invalid/redundant requests

Solution

Introduce a central coordinator that: 1. Validates incoming requests 2. Checks caches for existing results 3. Deduplicates concurrent identical requests 4. Composes work (determines which execution steps are needed) 5. Dispatches to specialized execution workers

Each execution worker owns a single capability and focuses purely on the transformation. Cross-cutting concerns (auth, caching, dedup, routing) live in the coordinator.

Consequences

Benefits: - Execution workers scale independently based on workload shape. - Cross-cutting improvements (better caching) benefit all workers at once. - Adding new execution types doesn't require changing the coordinator's core. - Workers are protected from invalid/duplicate traffic.

Costs: - Coordinator is a single point of failure (must be highly available). - Added network hop between coordination and execution layers. - Composition logic in the coordinator can become complex for deeply nested pipelines.

Relationship to control-plane/data-plane

This pattern is a specialization of concepts/control-plane-data-plane-separation applied to processing pipelines: the coordinator is the control plane (routing, composition, caching) and the workers are the data plane (actual transformation work).

Known instances

Seen in

Last updated · 590 distilled / 1,788 read