Cutting seconds of latency with a cache that wasn't actually caching
· 6 min
A backend running on a serverless platform, backed by a SQLite-compatible edge database, had a handful of endpoints that were consistently slow, not under traffic spikes, but even on a single isolated request in normal use. The business logic behind them was simple; nothing explained the delay.
Tracing the slowness to the data layer
The logs showed the time wasn't spent in the routes or in the database engine itself, but in something happening before any actual query ran. Every request passed through a dependency container that wired up more than ten repositories, and each repository, on construction, had a schema-initialization step meant to run only once per process.
The cache that existed on paper, not in code
The mechanism to avoid that repeated work was already designed: each repository held a reference meant to act as a cache of the "schema already validated" state. The problem was that reference was never actually read or set, it existed as a field, but nothing in the flow checked its value before redoing the work. In practice, that was equivalent to having no cache at all: every request rebuilt the entire container and, for each of its repositories, redid schema checks and adjustments, CREATE TABLE, column checks, conditional alterations, index creation, even on an already-warm process that had just done the exact same work on the previous request.
The fix: making the cache actually work
The fix wasn't architectural, it was making the caching mechanism that already existed actually function: populating and checking that per-repository state reference, so schema validation only ran the first time a process touched it, and holding the dependency container instance at module scope instead of rebuilding it on every call. The change was applied uniformly across every repository in the system, not just the ones flagged as slow, to avoid leaving the same bug latent elsewhere.
The result
Requests that used to take seconds because of that repeated work started responding in a few milliseconds, with no infrastructure change at all, just making the cache that was already designed into the code actually behave the way it was supposed to from the start.