Anatomy of the hot path.
One request's trip through the layer in front of every LayerKick store: a warm hit in about 9 milliseconds, a lot of measurement behind that number, and Shopify as the fail-safe when anything goes wrong. Most of June's engineering went here.
Since this went up I’ve advanced one of the layers into a contest between cloud providers! Whichever answers fastest now wins the serve. Early findings are promising, lower latency across the board. The twist worth its own entry: the winner changes country to country, so I’m now choosing the provider per country and re-measuring as it drifts, dogfooding our own A/B testing on ourselves. Full write-up in August.
A shopper taps a product link. Their request lands at the nearest Cloudflare colo, short for colocation, one of the few hundred data centers Cloudflare runs in cities around the world, so “nearest” usually means the same metro the shopper is standing in. There it meets the shim, the small worker that fronts every LayerKick storefront.
What happens in the next few milliseconds is most of what I spent June on. This is that stretch told as one request’s trip through the layer, though it’s closer to field notes than a schematic: the parts worth writing down turned out to be the things that surprised me, the alternatives I threw away, and the one arrangement I measured my way into and am not going to hand over. If you’re hoping for a blueprint you could rebuild from, this isn’t it, and the reason it isn’t is most of the story.
The shape is the boring part, and it’s the part everyone already knows: try the cheapest thing that could produce a page, fall to something more expensive only when the cheap thing comes up empty, and make sure the last resort is always just the store itself. Any CDN works roughly like that. What took the month was everything the shape doesn’t tell you.
The read path is sacred
The first thing I got religious about is who is waiting. On the read path there is a real person staring at a blank screen, so the rule became almost superstitious: nothing expensive is allowed to run while they wait. Not a hash, not a lookup that could be deferred, not a check that could just as easily happen a beat later. A warm hit comes back in about 9ms, and it stays there only because I keep moving work off that path.
That sounds obvious written down. It was not obvious in practice, and the way I learned it was by watching warm serves, pages already sitting in cache, blow their own deadline in far-off colos while the code stood around doing correctness work the shopper didn’t need yet. The fix wasn’t clever, it was a decision: the expensive, careful, has-to-be-right work moves to where nobody is waiting on it, and the read path is left holding almost nothing. The exact plumbing is Cloudflare’s to document, not mine, and it isn’t the interesting part anyway. The interesting part is the month it took to believe the read path should be that empty.
A single copy was always wrong somewhere
A miss at the colo used to mean giving up and letting Shopify render the page. Getting rid of that, without the cure turning out slower than the disease, is where the real time went.
Here’s the whole insight, and it’s free: any single place you keep the pages is wrong for somebody. Concentrate them and you’re fast for shoppers near the concentration and slow for everyone else. Spread them everywhere and you’re never terrible but never really fast either. I spent weeks trying to pick the right one before accepting that the right one doesn’t exist, and stopped choosing. On a miss the system now goes looking in more than one place at once and serves whichever answers first, and it quietly clocks the one that lost so it keeps learning which would have won.
That much is reusable and I’m glad to give it away, because knowing to do it is nothing. The part I measured my way into, over months of testing across regions and across cloud providers, where each kind of copy physically lives and whose infrastructure it sits on, which one is trusted when they disagree, which is allowed to leave a trace for the next visitor, and a stack of smaller choices under those that each moved real latency in directions I would not have guessed, is the part I’m keeping. Some of that measurement is still running: I keep more than one cloud provider benchmarked against the others, because the lowest-latency place to serve a page from isn’t obvious and doesn’t stay put. Not because any of it is magic. Because it cost months, and the forces that produced it are just physics, so anyone willing to spend the same months can rediscover it. This entry isn’t going to save them the months.
Freshness by correction, not by clock
The pages themselves are treated as permanent and replaced only when they actually change, rather than expiring on a timer. That’s a deliberate inversion of the usual cache bargain, where a short timer means you re-fetch constantly and a long one means you serve stale. Replace-on-change gets you both halves at once, fast and fresh, but it moves the entire difficulty into a single word: change.
Deciding a page “changed” is where a shopper would notice sloppiness, and on Shopify it is deceptively hard, because the same page comes back subtly reshuffled all the time in ways that change nothing a human sees. So the bar for calling something changed is set at what a shopper would actually perceive, not at whether a byte moved. Miss that judgment in one direction and you thrash the whole cache for nothing; miss it in the other and you serve yesterday’s price. That one judgment is doing more work than the rest of the machinery combined.
The floor is your store
The last thing in the chain fails on purpose. If anything at all goes wrong, a cold page, a bad cutover, a bug of mine, the request doesn’t error; it simply continues to Shopify, and the shopper gets the store exactly as it would have been if LayerKick weren’t in front of it. That is the guarantee I designed toward before I cared about a single millisecond: the worst case is what you normally have: Shopify.
A merchant is handing me the path between their shopper and their checkout. The only version of that I’d accept is one where the floor is the thing they already trust. Speed I’ll argue about. The floor I won’t. Everything above it, the racing and the caching and the paranoia about who’s waiting, is upside stacked on top of a guarantee that the thing underneath is just their store.
What’s next in the log
The pages in this entry were quietly starting to carry more than one identity, because a single URL can owe different shoppers different things. The next entry is about the moment that stopped being a footnote: running a price test through this same path without any shopper ever seeing a price that wasn’t meant for them.
LayerKick layers onto your existing Shopify theme and serves it from Cloudflare's edge. If anything goes wrong, traffic passes through to Shopify like we were never there. The fastest way to understand it is to watch it run on your own storefront, and the waitlist is the way in.