Engineering
Stress-Testing Sidekick Log for Large Inboxes
The first scaling problem was not AI. It was whether a Chrome extension could keep its memory intact under real inbox load.
A relationship radar is useless if it only works on a tidy demo inbox.
By May 2026, Sidekick Log had to survive thousands of Gmail threads, Chrome storage limits, MV3 service-worker interruptions, and multiple connected accounts without losing the state that made the product useful.
What we tested
The stress suite exercised inboxes from 5,000 to 20,000 threads under simulated API latency. The first high-priority signal appeared between 45 and 513 milliseconds across the test conditions, and the first five high-priority signals appeared in under two seconds.
In a 10,000-thread fixture with known labels, high-priority precision was 100%, low-priority precision was 100%, and the warm middle bucket measured 87.5% precision.
We also interrupted scans mid-run and resumed them from checkpoints, then tested two accounts with 3,000 threads each. The resumed scans produced no duplicate signals, stale checkpoints were rejected, and the account merge remained isolated.
The boring failures mattered more
The hardest production bugs were not dramatic model failures. They were Chrome failures.
A service worker died. Storage approached quota. A scan finished but the UI still believed it was indexing. A retry button called the wrong action. A large inbox wrote too much disposable metadata and crowded out the state that actually mattered.
Trust disappears long before the classifier becomes interesting if the product cannot reliably remember what it already knew.
What changed
Sidekick Log moved to checkpointed scanning, quota-aware storage writes, smarter eviction, recovery states, and account-scoped caches. At the 5,000-thread test scale, peak memory was 54 MB and storage peaked at 9.94 MB.
The engineering conclusion was less exciting than “we solved scale,” and more useful: the engine could carry the load well enough that infrastructure was no longer the main uncertainty.
The next bottleneck was relevance
Once a system can process the inbox, the problem becomes whether it should interrupt the user.
That changed the development priority. Faster scans mattered. Fewer false positives mattered more. The product stopped asking “can we analyze enough email?” and started asking “can we repeatedly surface something the person would actually have missed?”
That is a much harder benchmark.