One song on a playlist ends and the next one starts before you notice a gap. That is worth stopping on. Something chose the exact next song out of Spotify's entire catalog, in the space between one note ending and the next one beginning. It did not pause to think about it.
Here is the part most people get wrong. They picture the choice happening at the moment the song ends: some process wakes up, looks at your history, scores a few million candidate songs, and picks the best one, all in the half second before the next track starts. If that were true, you would hear it. A beat of dead air. A spinner. Some evidence that work was happening.
That is not what happens. The real work happened hours earlier. A background process, what I call a Worker, had already taken your recent listening and turned it into a compact summary of your taste. That summary got compared against millions of other songs, ranked by fit, and the winner got written down and held ready, sitting in a Queue or a Key-Value Store tied to your account, the kind of storage built for exactly one job: answer fast when asked.
So when the song actually ends, the app on your phone does not compute anything. It reads a value that was already sitting there waiting for it. The transaction is not "figure out the next song." It is "look up the answer to a question that was already answered."
Once you see that shape, you cannot stop seeing it. Gmail does not scan every email in your inbox the moment you hit search. A Worker already built a search index while you were doing something else, and your query reads that index instead of your inbox. Google Maps does not calculate current traffic the instant you open the app. Probe data from other drivers gets folded into an estimate continuously, in the background, so the ETA is sitting there the moment you ask for it. Your feed, on whichever app you check first each morning, did not start from nothing when you opened it. Most of the ranking work was already done.
Every one of these is the same trade: a Worker does expensive work on its own schedule, and a Queue or Key-Value Store holds the result until the exact moment someone needs it. The part the user sees is only ever a read.
The tempting move, the one that feels smart, is to compute the answer when the question actually arrives. That is when you know the most: the real time of day, the real device, the real thing the user just did three seconds ago. Waiting feels like the more accurate choice, and for a junior engineer it usually is the first instinct.
The senior move is the opposite. Spend the compute before the question shows up, and accept that your answer is built on slightly older information in exchange for one thing: the moment someone actually needs it, there is nothing left to do but hand it over.
In Course 1 I teach this shape by name, the Worker that does the early work and the Queue or Key-Value Store that holds the answer until it is needed.
You do not wait for the question to begin the work. You begin the work and wait for the question.
- Kay
P.S. If this is the kind of thing you want to start seeing everywhere once you know to look for it, the free course walking through all seven pieces is at https://systemthinkinglab.ai/learn/. This is one shape out of many, and it keeps showing up.
This letter goes out by email every Saturday. Subscribe here or read the full archive at systemthinkinglab.ai/newsletters.
Top comments (0)