Secondary Execution and Component Overlay #

Status: Archive candidate. Keep as historical reference; prefer system-design-core-index.md and the core notes for day-to-day use.

Secondary overlay note; not part of the active working set.

Use this note when the base archetype explains the authoritative state shape, but still does not fully explain why multiple systems feel mechanically similar.

This is a secondary overlay, not a replacement for archetypes.

Use it to answer questions like:

where does work get released?
who materializes runnable work?
who claims execution?
where do workers run?
what is the source vs sink vs bus?
what is serving path vs control path vs maintenance loop?

The overlay is most useful for infra-heavy and dataflow-heavy systems. It is much less useful for archetypes whose main complexity is market logic, collaborative merge semantics, or correctness around a single mutable truth boundary.

What The Overlay Adds #

Add these fields after you identify the dominant archetype:

Driver
- who coordinates the run or control loop?
- examples: scheduler, orchestrator, frontier manager, control plane
Job or Unit
- what is the logical work unit?
- examples: scheduled run, frontier shard, consumer batch, repair task
Worker
- who executes that work?
- examples: consumer, executor, fleet node, replica repair worker
Slot or Capacity Unit
- what bounded capacity constrains execution?
- examples: worker slot, pod, partition lease, concurrency token
State
- what authoritative state and attempt state exist?
Source
- where does input arrive from?
Sink
- where do outputs land?
Bus or Transfer Fabric
- if data or work moves through a queue/log/stream, what is it?
Maintenance Loop
- what background reconciliation, repair, compaction, rebalance, or reaping loop exists?

If the system has no meaningful answer for most of these, the overlay is probably not buying much.

Best Fit Archetypes #

These gain the most explanatory power from the overlay.

Highest Benefit #

A09 Future Constraint + Claimable Run
A10 Frontier + Claimable Run
I03 Due-Time Release + Claimable Run
I04 Frontier Scan + Claimable Run
I12 Workflow + External Side Effect
I15 Execution Fleet + Worker Substrate

Why:

they naturally have driver, runnable unit, worker, slot, attempt state, and reclaim loops

Strong Benefit #

I05 Append Log + Consumer Progress
I06 Projection / Index / Search Pipeline
I18 Telemetry / Time-Series Pipeline
I19 Replicated Chunk / Block / File Storage Substrate

Why:

they have clear source, sink, worker, background maintenance, and bus/state boundaries

Moderate Benefit #

I11 Control Plane + Snapshot Distribution
I16 Key-Scoped Mutable State / Replicated KV
I17 Traffic Steering / Request Mediation Plane

Why:

useful for separating control path, serving path, and background repair or propagation loops
but the base archetype already explains a lot

Low Benefit #

A08 Time-Bounded Exclusive Allocation
A12 Matching / Assignment
A16 Auction / Competitive Window
A17 Shared Mutable Subject
A18 Versioned Namespace + Immutable Content Units
I02 Claim / Lease / Exclusive Ownership

Why:

these are driven more by truth shape and correctness invariants than by a large execution topology

How To Use It #

Step 1: Pick The Archetype First #

Start with the dominant archetype:

truth shape
correctness boundary
primary failure phrases

Do not start with the overlay.

Step 2: Add Execution Fields Only Where They Clarify The System #

Example:

I03
- archetype tells you the system is time-gated runnable release
- overlay tells you:
  - driver = due scanner
  - job = logical scheduled run
  - worker = executor
  - slot = worker concurrency unit
  - maintenance loop = overdue reconciliation

Step 3: Separate Three Paths #

For systems that benefit from the overlay, explicitly split:

Control path
- config, policy, release decisions, checkpoints
Serving or execution path
- request handling or task execution
Maintenance path
- repair, compaction, rebalance, cleanup, retries, reaping

This is often where system-design explanations become much cleaner.

Typical Overlay Shapes #

Release -> Claim -> Execute #

Best for:

A09
A10
I03
I04
I15

Fields:

driver = scheduler or frontier manager
unit = runnable task
worker = executor
slot = fleet capacity
maintenance = reclaim/retry loop

Append -> Consume -> Progress #

Best for:

I05
I06
I18

Fields:

source = producers
bus = log/stream
worker = consumer/projector
sink = serving state or alert output
maintenance = replay, compaction, rebuild

Metadata -> Placement -> Repair #

Best for:

I19

Fields:

driver = metadata/placement manager
unit = chunk, replica, repair task
worker = storage node or repair worker
slot = node bandwidth/disk/concurrency
maintenance = rebalance, scrub, replica repair

Config Truth -> Snapshot -> Local Eval #

Best for:

I11
parts of I17

Fields:

driver = control plane
unit = config revision
worker = local proxy/agent
sink = local applied snapshot
maintenance = resync, replay, rollout reconciliation

When Not To Use It #

Do not force this overlay onto every question.

Avoid it when:

the dominant challenge is product truth and state transition correctness
there is no meaningful worker/slot/bus structure
it only restates the archetype in more words

If the overlay does not expose a clearer failure mode, bottleneck, or ownership boundary, skip it.

Relationship To Shared Execution Cores #

The shared-execution-core notes answer:

what reusable runtime kernel does this system resemble?

This overlay answers:

what concrete driver, unit, worker, slot, source, sink, and maintenance loop instantiate that kernel here?

So the layers are:

dominant archetype
shared execution core
secondary execution/component overlay
decorators:
- I08
- I11
- I18
- I07

Short Rule #

Use the secondary execution/component overlay when the system has a real runtime topology:

driver
runnable unit
worker
slot
source or sink
maintenance loop

The biggest winners are:

A09, A10
I03, I04, I05, I06
I12, I15, I18, I19