Tensions in Practice: Even work placement in tension with data locality¶
Parallel workers · cached data
Two workers can run the same task, but only worker A already has the needed data close at hand. A is busy; B is idle. Sending the next related request to A preserves that local advantage. Sending it to B uses spare capacity but requires fetching data first. Equalizing the queue lengths and minimizing this request’s work are different objectives.
Use available capacity
Move work away from a busy worker while another can help.
Preserve local reuse
Keep related work near data or state it can already reuse.
Why these aims pull against each other
Workers can be interchangeable in capability while differing in their preparation for a particular request. A placement that spreads load can add data-access work.
Choose an arrangement to see what changes and what remains difficult.
Qualitative paths and conditions, not measured costs, timings or performance guarantees.
What this choice protects
What it costs
When it fits
Compare the arrangements
Follow the data
Route the related request to A, reusing its local data.
- What it protects
- The request avoids the extra fetch needed at B.
- What it costs
- A receives more work while B’s capacity stays unused.
- When it fits
- The local-data benefit outweighs the additional waiting and A remains within its acceptable load.
Illustration note: The two-worker example is editorial; no cache-hit timing or overall speed ranking is measured.
Follow spare capacity
Route the request to B and obtain the data B needs.
- What it protects
- B contributes capacity instead of leaving all related work at A.
- What it costs
- The fetch consumes time and resources; a less busy worker need not answer sooner.
- When it fits
- A’s congestion matters more than the transfer cost, and B can access the needed state correctly.
Illustration note: The fetch path is a schematic of the source’s locality cost. It does not assume state can always be copied or that migration preserves every session contract.
What this illustration does—and does not—establish
Load Balancing: Balancing assumes interchangeability that real units rarely fully honor supplies the locality conflict. The unchanged worker pool makes the changed routing and extra data path visible.
- No arrangement creates capacity or guarantees lower latency.
- The example concerns data locality, not failover or the correctness of copying mutable session state.
Source entries
Load Balancing
Load Balancing: Balancing assumes interchangeability that real units rarely fully honor supplies the conflict examined here.
Balancing assumes interchangeability that real units rarely fully honor
T3: Balancing assumes interchangeability that real units rarely fully honor. The pattern's power comes from treating units as substitutable, but units differ — in capacity, in warmed caches, in locality, in residual state. Routing a request to the "least-loaded" server may be wrong if that server lacks the cached data the request needs, turning a balanced placement into a slow one. The more the units carry per-unit state or affinity, the more balancing for evenness fights against balancing for locality, and the two objectives pull in opposite directions.