Preload Belongs to the Resource Owner
Preload belongs to the resource owner
Preloading is tempting because it feels like free latency. It is not free. It touches ownership.
The safest preload path is the one exposed by the subsystem that owns the real resource: the player for audio buffers, the database for prepared pages, the HTTP cache for remote responses, the image cache for decoded artwork.
The rule
Do not build a parallel preload path around the resource owner unless you are deliberately taking ownership of that resource too.
Otherwise you get duplicate caches, invalidation bugs, and warm work that looks successful but is invisible to the thing that actually needs the data.
Why this matters
Audio is the clearest example. A daemon can fetch metadata for the next track, but it cannot prewarm a remote Spotify Connect device's audio buffer from the outside. The buffer lives in that remote player.
If the daemon embeds the player, the shape changes. Now the daemon owns the player backend, so it can ask that backend to preload the next URI through the player's native API. The preload still belongs to the player. The daemon just has a legitimate way to request it.
Spotuify now follows that shape for queued tracks. The queue warmer can ask
the embedded player to preload the next URI, but it does not build a second
audio cache beside the player. The player actor still prioritises transport
commands before warm preload work, because a preload is allowed to lose to
play/pause.
General examples
- Use the browser or HTTP cache's own preload path instead of saving a second copy beside it.
- Use the database/cache layer's API instead of reading files behind its back.
- Use the media player's preload hook instead of inventing a side buffer the player will never consume.
- Use the search index writer's batching model instead of mutating index files directly.
The instinct is good: make the future action fast. The implementation has to respect ownership.