ERP integrations love stock updates. Every one of them purges Varnish for the product and, through its cache tags, the parent categories it sits in. Categories shared by many products get purged over and over, so a busy sync can keep the full page cache close to empty.
I built this ahead of Black Friday 2024 as an experiment, then rolled it out to stores with problematic ERP systems. The idea is that most purges can wait a few minutes.
What does debouncing the purges change?
Purges stop arriving one stock update at a time. The module queues the cache tags and flushes them together on a schedule, every 15 minutes by default, so you trade up to one interval of staleness for far fewer purges.
The README carries the only measurement, the dashboard at the top of this page. A fresh Luma store with sample data on a Hetzner CPX31 (4 vCPU, 8GB) was crawled back to back by a Go sitemap crawler, while a script set a random stock quantity on a random SKU every second through the PUT StockItems route. The module was switched on halfway through a 30-minute run on 6th November 2024.
Varnish purges fell to almost nothing, cache hits rose, and backend transaction time dropped sharply. That is one lab run, not a client store, and no production figures are published.
How do I install Cache Debounce?
composer require samjuk/m2-module-cache-debounce
php bin/magento setup:upgrade && php bin/magento cache:flush| Option | Config path | Default |
|---|---|---|
| Enabled | samjuk_cache_debounce/general/enabled | 0 |
| Flush schedule | samjuk_cache_debounce/cron/flush_schedule | */15 * * * * |
The schedule is a cron expression, validated when you save it. Since 17th September 2026 the flush runs in its own samjuk_cache_debounce cron group, so a slow flush never holds up the default group. If your crontab runs cron:run --group for each group rather than a plain cron:run, add this one. bin/magento samjuk:cache-debounce:flush empties the queue on demand.
How does it hold the purges back?
It catches the purge request on its way to Varnish. An around plugin on Magento\CacheInvalidate\Model\PurgeCache::sendPurgeRequest stores the cache tags in the samjuk_cache_debounce table and reports success instead of sending the purge. The cron job then flushes the queued tags.
Will it help my store?
Only if purges are the problem, so count them first. Debug logging writes a cache_invalidate entry to var/log/debug.log for every invalidation:
php bin/magento setup:config:set --enable-debug-logging=true && php bin/magento cache:flushIf debug logging in production is not an option, the README has a one-line patch that logs the same entries at info level into system.log instead.
What does it leave alone?
- Magento’s built-in full page cache. Only Varnish purge requests are debounced.
- The purges themselves. They are delayed, not dropped. If you would rather disable them entirely, Hypershop_SpikePerformance is the more aggressive option.
CI runs PHPStan, PHPCS, unit tests, setup:di:compile and integration tests on six Magento versions, 2.4.3-p2 to 2.4.8-p3, across PHP 7.4 to 8.4. The latest run on master, from 17th September 2026, passed. Kevin Meijer contributed consistent purge tag handling in #2.
What went wrong
The first versions could lose tags. The queue was cleared before the purge was confirmed, so a failed purge threw its tags away, and tags added while a purge was running could disappear. Both were fixed between 10th and 13th July 2026, along with a guard against an empty tag array.