Developing a Caching Module for 1C-Bitrix on Redis

When your Bitrix site slows down, the /bitrix/cache/ folder balloons to 40GB, and database locks under load, the standard file cache is no longer viable. A Redis-based caching module addresses these issues head-on. On one project with a catalog of 500,000 items, the file cache grew to 40GB, and read operations were blocking the database. Switching to a Redis backend achieved a 98% hit rate, reduced latency by 90%, and enabled atomic tag invalidation. With over 10 years of Bitrix development experience and 40+ similar projects, we design robust caching solutions tailored to your architecture. Contact us for a free analysis and a turnkey proposal.

Why Redis outperforms file cache

File cache doesn't scale across multiple servers, read/write operations are locked at the filesystem level, and tag invalidation is a blocking operation. Redis executes queries in memory, with 90% lower response time. Atomic operations (Sets, Lists) make invalidation instantaneous. In practice, a Redis module achieves a 98% hit rate, while file cache rarely exceeds 85%. Load testing with 1,000 concurrent requests showed Redis handling all requests in 120 ms versus 450 ms for file cache.

CacheManager architecture

The central CacheManager class implements the strategy pattern. The backend is selected in module settings:

$cache = \Vendor\Cache\CacheManager::getInstance(); // Standard get-or-set $result = $cache->remember('catalog_section_12', 3600, function() { return CIBlockSection::GetList(/* ... */)->Fetch(); }, ['iblock_12', 'catalog']); // → Data from cache or result of callable on miss // Explicit tag invalidation $cache->invalidateTag('iblock_12'); // → All keys tagged with iblock_12 are cleared 

Redis backend: atomic tag invalidation

Tags are implemented via Redis Sets. Invalidation is atomic with no filesystem locks:

class RedisCacheBackend implements CacheBackendInterface { private \Redis $redis; public function get(string $key): mixed { $data = $this->redis->get($key); return $data !== false ? unserialize($data) : null; } public function set(string $key, mixed $value, int $ttl, array $tags = []): void { $serialized = serialize($value); $this->redis->setEx($key, $ttl, $serialized); // Tags stored as Redis Sets foreach ($tags as $tag) { $this->redis->sAdd("tag:{$tag}", $key); $this->redis->expire("tag:{$tag}", $ttl + 3600); } } public function invalidateTag(string $tag): void { $keys = $this->redis->sMembers("tag:{$tag}"); if ($keys) { $this->redis->del(...$keys); } $this->redis->del("tag:{$tag}"); } } 

Four caching strategies

We apply four strategies depending on data type:

• TTL cache — classic time-to-live for rarely changing data: site settings, regions, shipping.
• Event invalidation — reset on Bitrix events (OnAfterIBlockElementAdd, OnAfterIBlockElementUpdate, etc.).
• Stale-while-revalidate — serve stale cache instantly, trigger background regeneration via an agent. Eliminates thundering herd on miss.
• Request-scoped — in-memory array for a single HTTP request, avoiding repeated DB queries.

Want to determine the optimal strategy for your project? Contact us for a consultation.

Cache warmup to prevent spikes

After cache flush, the first request hits the database. Under high load, this causes a spike. A warmup agent solves this:

// Registered warmup tasks $cache->registerWarmup('catalog_menu', function() { return CIBlockElement::GetList(/* full catalog */); }, ['iblock_main_catalog'], 7200); // Agent runs hourly and refreshes cache before TTL expires \Vendor\Cache\WarmupAgent::run(); 

Monitoring and statistics

Table b_vendor_cache_stat stores aggregate stats per key:

• key_prefix, hits, misses, avg_ttl, last_hit_at

Admin interface includes:

• Hit rate by key category
• Top "cold" keys (>20% misses)
• Cache size per backend
• Manual invalidation by tag or key
• Log of recent invalidation operations

How to integrate with existing components?

Standard components use $APPLICATION->IncludeComponent() with CACHE_TYPE parameter. The module intercepts this mechanism and redirects to Redis:

// In init.php after module inclusion \Vendor\Cache\BitrixCacheBridge::install(); // → Overrides \Bitrix\Main\Data\Cache::createInstance() // returning Redis backend instead of file 

The bridge makes the swap transparent—components continue working without code changes.

Process: from audit to deployment

1. Analysis — study current architecture, measure performance (XDebug, MySQL slow log), identify bottlenecks.
2. Design — design module schema: select strategies, design tag structure, coordinate with you.
3. Implementation — write CacheManager code, backends, agents, bridge.
4. Testing — load testing with JMeter (1,000 virtual users) and metric collection.
5. Deployment — install on staging and production, monitor for one week.

What's included

Timeline and cost

Total: 10–12 working days. Code warranty: 1 year. Development cost is calculated individually. For projects with a PHP server cluster—additional Redis Cluster or Sentinel setup: +1–2 days.

Learn more about Redis and caching principles.

Assess your site's current performance: we offer a free caching audit in 2 days. Order a caching module to keep your site fast and stable under any load—contact us for a consultation!