The cache that finally stuck

AutoSync is the platform thousands of Canadian dealerships run their inventory on. It was a large codebase I didn’t design, shared with other engineers: Vue on the front end, and Node.js, PHP, MySQL and REST APIs behind it. The PHP was our own object-oriented architecture, built in-house with no Laravel or Symfony, so the hard questions were about our own design, with no framework conventions to lean on.

If you look at one thing from these five years, make it the caching. It did make pages faster, but the bigger win was stability: the platform stopped falling over.

Problem

For three years, the object cache kept getting added, removed, swapped for other plugins and reverted, with hotfixes after deploys to switch it back on. As I saw it, the churn was a reaction to downtime.

My part

I backed out the approach that kept getting reverted, moved the platform to Redis Object Cache Pro and created its repository. I wrote 33 of the 36 commits to the platform’s Redis configuration, and later rolled page caching out across the fleet.

Decision

A dedicated Redis host in production (I chose not to use a cluster there) and shared clusters in dev and staging. Per-site key prefixes, global groups and non-persistent groups let a fleet of sites share one cache, and I worked through the flush and prefetch settings with the plugin’s author.

Trade-off

Page caching leaves out the inventory and showroom routes, because those pages can never be served stale.

Rollout

I proved it out on a separate test network first, load-test configuration included. It went down once during cluster testing, which is why the testing ran separately. It shipped through the release scripts so every dealer site came up the same way, and went live in March 2022. Page caching followed later, rolled out to the whole fleet with WP-CLI and wired into the deploy scripts.

Outcome

Nobody reverted or removed it in the three years after, right up until I left. Because it held, the team started building on it; a colleague later cached the CARFAX auth token in it. This comes from the private repository’s history, like the commit counts. It isn’t an uptime figure.

I can count what I wrote, because the repository counts it for me. What I can’t tell you is what the caching did to page speed or conversion. I didn’t own those dashboards, and I didn’t take the numbers with me when I left. So you won’t find a percentage here, and I won’t make one up. What I can describe is the failure mode before, and that it didn’t come back. I’d rather explain how something worked than quote a number I can’t back up.

Outside the caching, I worked on technical SEO for a marketplace where getting dealer inventory found is the product, not a marketing extra.

All of it was team work. We ran Agile, reviewed every change, and paired when something mattered enough to be worth two people’s time. I reviewed other engineers’ work and had mine reviewed, in a codebase I couldn’t change on my own say-so. That’s the more common way to work, and a different discipline from my studio year. I also mentored engineers through code review and pairing, which is where the review habits on this site come from.

I’d have kept my own record. Since then, every project on this site gets a measurement written in before a feature ships. That habit started with the one question this page can’t answer.