The cache that doubled as a coordinator

4 June 2026

2 min

The rendering engine is what visitors see. The data layer feeds it, and keeping it stable under load was the less glamorous half of the build.

This is the second post in the ON Labs series. The first covered the WebGL engine: shaders, draw calls, the GPU-level stuff. This one is about what happens before a single pixel renders: fetching project data from an external API, caching it and making sure concurrent requests don’t trip over each other.

The original problem

Labs pulls project boards and media assets from Air.inc. Early on, every page request made a fresh API call. It worked fine in development and immediately hit rate limits in production. Multiple serverless instances spinning up at once meant dozens of identical requests hitting the same endpoints within seconds.

You can’t just “add a cache” when you don’t control how many instances are running or when they start.

One request rebuilds, the rest wait

The core idea is coordination: when the cache expires, only one instance rebuilds while the others wait. If the rebuild takes too long or fails entirely, stale data gets served instead of an error. A crashed process can’t hold the lock forever; it expires on its own.

One request rebuilds. The rest wait or serve stale. No stampede.

It’s stale-while-revalidate implemented in application code, because the hosting layer doesn’t offer it natively for API-driven data. The storage layer doubles as both cache and coordination mechanism between instances that have no other way to communicate.

Cache versioning and the video pipeline

The cached payload carries a version number. When the data shape changes (new fields, restructured assets) the version bumps and every instance treats the old cache as expired. No manual purging, no deploy-time clears.

A separate store handles optimised video URLs. Each asset’s source maps to transcoded variants at different quality levels, cached per-asset with their own expiry. A concurrency limit keeps the transcoding lookups from overwhelming the provider.

Labs loads quickly. Transitions run smoothly. Filters respond without delay. Nobody sees lock negotiation or stale fallbacks or version checks. They see a portfolio that works.

What the data layer protects: a fast, reliable first impression.

Why build this yourself

Most caching is straightforward: set a TTL, serve from cache, refresh when it expires. The complication is concurrency across serverless instances with no shared memory. Off-the-shelf HTTP caching doesn’t solve that. Coordination in a stateless environment means leaning on a shared store and building the locking yourself.

Not glamorous work. But without it, two people visiting at the same time could bring the whole thing down. That’s not hypothetical.

Twenty-four modules, one wrapper

Andy Purbrick

Field Notes

28 May 2026

3 min

Every case study was its own Astro page. That was the first problem.

Each page had its own layout logic, its own spacing decisions, its own way of handling full-bleed sections versus contained text. Some used inline styles. Some used one-off SCSS files. None of them agreed on what “default spacing” meant. Adding a new case study meant copying an old one, deleting most of it and hoping the parts you kept still worked together.

We needed a system where content authors write markdown and the layout stays consistent without anyone thinking about it.

The contract

The fix started with a single SCSS file: the contract. It defines every spacing and layout value the site is allowed to use, from page max-width and gutters to three tiers of vertical spacing and text measure widths. All fluid, all using CSS clamp() so they scale smoothly between mobile and desktop.

No component gets to invent its own spacing. Every module reads from these tokens. If a value isn’t in the contract, it doesn’t exist. One file changed, every page updates.

Side-by-side: the same case study page at mobile (375px) and desktop (1440px). Modules reflow and spacing stays proportional. The same modules at two viewport widths, layout adapts, spacing stays proportional.

Inside the wrapper

We built 24 components (Hero, TextColumns, Cards, ImageText, Slider, ClientQuote and 18 others) that all sit inside a single wrapper. The wrapper accepts a small set of layout attributes, each with a few named values that control width, spacing and proportion. CSS custom properties handle the rest.

The content author never writes layout code. They write container directives in MDX:

:::text-columns{layout="double" spacing="compact"}

Mosaic of rendered module types cropped from real case studies: Hero, TextColumns, Cards, ClientQuote, Slider, ImageText. A sample of the 24 modules. Each one only knows about its own content; the wrapper handles everything else.

The case study template maps each directive name (hero, text-columns, image-text, client-quote) to the matching component. The author picks which modules they want and in what order. The system enforces how those modules look.

What modules don’t need to know

Twenty-two case studies and five landing pages now run through the same template. Before, each page was a standalone Astro file with its own layout logic.

The surprise was how little the modules need to know about each other. A Hero doesn’t care what follows it. A TextColumns block doesn’t know if it’s inside a case study or a landing page. The contract handles the shared rules, ModuleSection handles the shared structure and each module only worries about its own content.

What actually ships

A content author opens an .mdx file, writes directives, saves it and the page is done. No custom template, no per-page SCSS. A new case study that used to take a developer half a day now takes about twenty minutes. Client work gets published faster, and nobody has to ask a developer to adjust spacing.