---

Remember waterfalls?

You ask for one thing. Then, only once that comes back, you ask for the next thing. Then the next. Each request politely waits in line for the one ahead of it, even when it has no reason to.

On a single page, in a single component tree, waterfalls are easy to create by accident. You await something, and everything below that line now lives after it in time — whether it needed to or not.

This post is about one specific waterfall. The one that shows up on almost every storefront built on a federation layer like the Alokai Middleware. It's small. It's defensible. And it's worth understanding precisely, because the moment one assumption changes, it stops being small.

Let's look at a product listing page.

---

1 The Page

Here's the shape of a category page. I'll strip it down to the part that matters:

export default connectCmsPage(async function CategoryPage(props) {
  const { categoryData, productCatalog } = await buildCategoryPageData(props);
  return <CategoryGrid category={categoryData} products={productCatalog} />;
});

Two things are happening here, and they're easy to read right past.

The first is connectCmsPage. It's a higher-order component — a wrapper. Before your CategoryPage body ever runs, the wrapper awaits the CMS. It fetches the page definition (getPage, or getPersonalizedPage when personalization is on), maps the locale, sets up preview-mode rerendering, wraps everything in the live-preview shell. All of that cross-cutting machinery lives in one place, and every page type — category, product, home, a plain CMS page — gets it for free by wrapping.

The second is buildCategoryPageData. Inside it, the commerce data is fetched in parallel, the way you'd want:

const [categoryData, productCatalog] = await Promise.all([
  getCategory(categoryId),
  sdk.unified.searchProducts(searchProductsQuery),
]);

So getCategory and searchProducts race each other. Good. Nobody's waiting on nobody.

Except — look at where the two pieces sit relative to each other. The CMS fetch is in the wrapper. The commerce fetch is in the body. And the body is the wrapper's child. A child can't start until its parent has resolved.

So even though the product search doesn't need a single byte from the CMS, it can't begin until the CMS call is done. The products wait on the CMS — not because they depend on it, but because of where they live in the tree.

It would be tempting to call this a bug. It isn't. It's a tradeoff someone made on purpose, and to know whether it's the right one, you have to know how much that first hop actually costs.

---

2 Sometimes the Hop Is Free

Here's the thing about the CMS call: content doesn't change very often. A category's merchandised layout — the hero, the banners, the promo blocks — gets edited by a marketer maybe a few times a week. Which means getPage is almost always a cache hit. Something close and warm. Single-digit milliseconds.

So picture the timeline with real numbers. CMS is a cache hit at ~10ms. The product search is the slow one, because it's a real query against a search engine — call it ~200ms.

---

3 Where "Cheap" Comes From

I said getPage is "almost always a cache hit" and waved at "something warm." Let me not wave. Which cache, and why it's warm, is the whole ballgame — because personalization is about to switch some of these off, and you want to know exactly which lights go dark.

There isn't one cache in front of the CMS call. There are four, stacked, each catching what the one above it missed:

And there's a layer you don't even run: the CMS's own delivery API is already a CDN. Contentful's Content Delivery API is, in their words, "available via a globally distributed content delivery network (CDN)" that purges on publish; Contentstack serves its CDA from edge caches too, purging "only the changed content" when you publish. So for published pages, that "origin" at the bottom of the ladder is rarely a cold read — it's another edge hit, and it's very likely the real reason getPage is cheap in this demo even with no Redis installed. The documented exceptions line up exactly with the slow case: preview (a separate, non-CDN endpoint) and per-user content (nothing shared to cache) don't get that benefit.

The layer that makes "~10ms getPage" cheap on your own infrastructure — once you outgrow the provider's CDN, or go per-user — is Layer 3, Redis, and it's the one people forget. Alokai's Redis integration is an SDK module — sdk.redis.getOrSetCache(key, fetcher, { tags }). Unlike the edge caches, it's explicit (you wrap the call) and tag-based (you invalidate by meaning, not by clock). Wrap the CMS read in it and the first render populates Redis; every later render — across every SSR instance — reads from Redis until a CMS publish webhook invalidates the page: tag. You drop exactly the page that changed, the instant it changes.

Which is exactly the setup for what comes next. Because the moment you personalize, you start switching these layers off, from the top down.

---

4 Sometimes the Hop Is the Whole Story

Now turn on personalization. But "personalization" isn't one thing — and the difference is the whole story for caching.

This isn't a hand-wave — it's how the products actually work. Contentful's edge rendering says the list of assigned Experiences "can serve as a cache key so that subsequent visitors can be performantly served the same combination of Experience content." Contentstack likewise "caches the personalized web page against the request URL and the applied variants." The key is the segment, not the person — so a thousand shoppers in the same audience share one cached page.

So the real lever isn't "personalized or not." It's the cardinality of the cache key. Anonymous is one key. Segmented is N keys — fine while N stays small. Per-user is roughly one key per visitor, and that is the only case where the cache genuinely can't help. (Watch for combinatorial blow-up, though: stack enough audiences × geo × A/B tests and N quietly explodes, thinning the traffic per variant until the hit rate sags back toward the 1:1 cost.)

The expensive case below is that last one — true 1:1. When the page is a function of this user's identity, cart, and history, there's nothing shared to cache, so getPersonalizedPage becomes an origin round-trip with a session attached. Call it ~180ms, and it sits fully in front of the commerce calls.

Same code. Same tree. Same waterfall. But the cost went from ~10ms to ~180ms, because the assumption underneath it — "the CMS call is basically free" — quietly stopped being true. The page didn't change. The cache behavior did.

The per-user page can't sit on a shared edge — layer 1, dark. The per-user data can't either — layer 2, dark. And Redis can't share a per-user entry; at best it caches per user, a sliver of the hit rate — layer 3, mostly dark. You fall all the way through to the origin. That isn't a metaphor; it's the literal mechanism.

And there's a sharper point hiding here, one that should make you more cautious about parallelizing, not less. On a personalized page you may not even know you're fetching the right products yet. In B2B, contract pricing, or customer-group catalogs, the commerce call carried with a session can return different prices — and a different set of visible products — per shopper. If the personalized CMS is what decides the merchandising, then firing searchProducts in parallel risks fetching the wrong catalog, not merely a catalog you discard. Now you're not paying for wasted work, you're paying for incorrect work, plus the refetch — which spends the exact latency you parallelized to save. (In the code we looked at, the product query is built from props, not the CMS payload, so this only bites once personalization actually reshapes the product context. But the moment it does, it's the best argument on the page for staying CMS-first.)

---

5 What Federation Could Do Instead

The federation layer's whole job is to sit between the storefront and a pile of backends — CMS here, commerce there, search somewhere else — and decide how to talk to all of them. Which means it's exactly the layer that could fetch them together. If the three independent calls ran in one batch — by hoisting the commerce promises above the CMS await, or by adding a middleware endpoint that orchestrates all three server-side — you'd get this:

So why isn't it just always done this way? Because "for free" is doing a lot of work in that sentence. It's free in latency. It is not free in everything else.

---

6 The Honest Ledger

Here's the whole trade laid out, because the latency win is real but it is not the only column.

---

7 The Principle

A design that's correct under an assumption is only as correct as the assumption. The CMS-first ordering is right because CMS reads are cheap and cacheable — and we now know "cheap" means a warm, shared, tag-invalidated cache is sitting behind the federation layer. So the thing to actually do is not "parallelize everything" and not "leave it alone forever." It's: measure the assumption.

A cold or absent Redis layer will make the CMS hop look expensive no matter how you order the calls — and so will a page that's truly per-user when it didn't need to be. Check the cache-key cardinality before you blame the waterfall: if the page is segmented, it's cacheable and the hop should be cheap; if it's genuinely 1:1, no ordering trick brings the shared caches back. Only once the cache is warm, the page is as shared as it can be, and the hop is still slow does reordering start to pay. Watch getPage / getPersonalizedPage latency at p75 and p95, and let the numbers tell you which world you're in.

---

8 Tips — Do's & Don'ts

Most cache problems come down to something small — a single header or key that quietly flips a shareable response into a per-user one. Here's what keeps the layers warm, and what silently turns them off.

---

9 What Not to Cache in Commerce

Some commerce data should never sit in a shared cache — not because of latency, but because caching it is wrong: it serves one shopper another's data, oversells stock you don't have, or quotes a price the customer was never entitled to. Alokai's own guidance splits the offenders into two buckets — time-sensitive and session-specific data — and both are commerce-specific.

And here's the part that's really about federation, not just caching: the cleanest rule isn't to maintain a per-endpoint blocklist — it's to not federate session- or time-sensitive data into the cached page at all. Keep the SSR payload identical for every shopper, and pull the personal, volatile bits in a second step on the client (Alokai's docs show exactly this — a useEffect fetch behind a skeleton). The shared shell caches beautifully; the per-user fragment never touches the cache. The same logic kills the tempting "one merged endpoint for the whole page" idea: fuse volatile price/stock onto stable content and the combined entry inherits the shortest TTL, so you've cached the slow-changing content for as long as the fastest-changing field allows — which is to say, barely.

---

Built on the Alokai Middleware. The numbers here are illustrative — yours are in your traces. Go look at them.