Magento 2 Cache Types — Complete Management & Custom Cache Guide

CodeAtoZ Engineer, CodeAtoZ
11 min read · 2061 words
Share: 𝕏 in
DEV DEEP DIVES · MAGENTO 2 DEVELOPER GUIDE #16

Magento 2 Cache Types — Complete Management & Custom Cache Guide (2026)

Every Magento 2 cache type explained — when to flush vs clean, Redis configuration, Varnish full_page cache, custom cache type creation, and selective invalidation from PHP.

15Cache types
RedisRecommended
VarnishFull page
2026Updated

Understanding Magento 2 cache types is essential for both performance and debugging. Magento 2 ships with 15 built-in Magento 2 cache types — from configuration and layout to compiled code and full-page cache — each storing different categories of computed data. Knowing which Magento 2 cache types to flush when, which to flush selectively versus globally, and how to create a custom cache type for your module data prevents the two most common performance anti-patterns: flushing everything on every deploy (slow) and never flushing the right type (stale data bugs).

Magento 2 cache types fall into three tiers: backend caches stored in Redis or files (configuration, layout, block HTML), the full-page cache served by Varnish or Magento’s built-in FPC, and opcode cache managed by PHP-FPM. Understanding which tier a cache type belongs to determines both where its data is stored and how to invalidate it correctly.

magento 2 cache types — complete guide to all 15 types Redis Varnish full page and custom cache by CodeAtoZ
Magento 2 cache types — all 15 built-in types with storage tier and when to invalidate each

Magento 2 Cache Types: Complete Reference Table

Every Magento 2 cache type has a specific scope, storage location, and correct invalidation trigger. Understanding this prevents unnecessary full-flush deployments.

Cache typeCLI nameWhat it storesWhen to flush
ConfigurationconfigMerged config XML, system.xml, env.phpAfter any config change or deploy
LayoutslayoutCompiled page layout XML treesAfter layout XML changes
Blocks HTML outputblock_htmlRendered block HTML fragmentsAfter template or CMS changes
Collections datacollectionsDatabase collection query resultsAfter product/category data changes
Reflection datareflectionAPI interface reflection metadataAfter module adds/removes
DB DDL operationsdb_ddlDatabase schema descriptionsAfter schema changes (setup:upgrade)
Compiled configcompiled_configDI compilation outputAfter setup:di:compile
EAV types/attributeseavEntity attribute metadataAfter attribute creation/modification
Customer notificationcustomer_notificationCustomer inbox messagesRarely — automatic
Config integration APIconfig_integration_apiIntegration API token metadataAfter integration changes
Config integrationconfig_integrationIntegration configurationAfter integration changes
Google Product Cachegoogle_productGoogle Shopping product feedsAfter product data changes
Full-page cachefull_pageComplete rendered HTML pagesAfter any frontend change
Vertex tax datavertexVertex tax calculation dataAfter tax config changes
TranslationstranslateCompiled i18n translation filesAfter translate.csv changes

Magento 2 Cache Types: Flush vs Clean — The Critical Difference

Magento 2 offers two cache clearing commands and they behave differently. Understanding this distinction prevents accidental over-clearing in production:

Shell — cache:clean vs cache:flush in Magento 2 cache types
# cache:clean — cleans ONLY Magento's registered cache types
# Safe for production — does not touch third-party cache storage
bin/magento cache:clean config layout block_html

# cache:flush — flushes the entire cache STORAGE (Redis/file)
# Clears ALL data including third-party caches sharing the same storage
# Use for deployments, not routine cache management
bin/magento cache:flush

# Flush only specific Magento 2 cache types by name
bin/magento cache:clean full_page collections eav

# Disable/enable specific Magento 2 cache types
bin/magento cache:disable block_html full_page
bin/magento cache:enable block_html full_page

# Check status of all Magento 2 cache types
bin/magento cache:status

Magento 2 Cache Types: Create a Custom Cache Type

Custom Magento 2 cache types let your module store computed data that is expensive to regenerate. Register your cache type in etc/cache.xml and use the cache frontend API in your PHP service class.

XML — etc/cache.xml (register custom Magento 2 cache type)
<?xml version="1.0"?>
<config xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xsi:noNamespaceSchemaLocation="urn:magento:framework:Cache/etc/cache.xsd">
    <type name="vendor_custom_data"
          translate="label,description"
          instance="VendorModuleModelCacheTypeCustomData">
        <label>Vendor Custom Data</label>
        <description>Custom computed data for Vendor module</description>
    </type>
</config>
PHP — use custom Magento 2 cache type in a service class
<?php
namespace VendorModuleModel;

use MagentoFrameworkAppCacheInterface;
use MagentoFrameworkSerializeSerializerInterface;

class ProductDataService
{
    private const CACHE_TYPE = 'vendor_custom_data';
    private const CACHE_TTL  = 3600; // 1 hour

    public function __construct(
        private readonly CacheInterface      $cache,
        private readonly SerializerInterface $serializer
    ) {}

    public function getExpensiveData( int $productId ): array
    {
        $cacheKey = 'vendor_product_data_' . $productId;
        $cached   = $this->cache->load( $cacheKey );

        if ( $cached ) {
            return $this->serializer->unserialize( $cached );
        }

        // Expensive computation here — only runs on cache miss
        $data = $this->computeProductData( $productId );

        $this->cache->save(
            $this->serializer->serialize( $data ),
            $cacheKey,
            [self::CACHE_TYPE],  // tag for selective invalidation
            self::CACHE_TTL
        );

        return $data;
    }

    private function computeProductData( int $productId ): array
    {
        // ... expensive calculation
        return [];
    }
}

💡 Use cache:clean instead of cache:flush in your Magento 2 CI/CD deployment post-deploy scripts. cache:flush wipes the entire Redis storage including session data, which can force all logged-in customers to log back in immediately after a deploy. cache:clean config layout full_page clears only the Magento 2 cache types that actually changed during the deploy without touching sessions.

The Adobe Commerce full page cache documentation covers Varnish configuration for the full_page Magento 2 cache type. The Magento 2 partial cache documentation covers custom cache type creation and the cache tag invalidation API. See our Magento 2 CI/CD deployment guide for how cache commands fit into the deployment pipeline, and our Magento 2 development services for performance-optimised Magento builds.

Frequently Asked Questions — Magento 2 Cache Types

What are the Magento 2 cache types?

Magento 2 ships with 15 built-in cache types: config, layout, block_html, collections, reflection, db_ddl, compiled_config, eav, customer_notification, config_integration_api, config_integration, google_product, full_page, vertex, and translate. Each stores a different category of computed data. The full_page type stores rendered HTML pages and is typically served by Varnish or Magento’s built-in FPC. All others are stored in Redis or the file system.

What is the difference between cache:clean and cache:flush in Magento 2?

cache:clean removes data only from Magento’s registered cache types — it does not touch the underlying cache storage (Redis/files) beyond what Magento manages. cache:flush wipes the entire cache storage, including any third-party caches sharing the same Redis instance and session data. Use cache:clean for routine invalidation and specific type clearing. Use cache:flush only during full deployments when a complete reset is required.

Which Magento 2 cache types should I flush after a deployment?

After a standard code deployment: clean config (always), layout (if any layout XML changed), block_html (if any templates changed), compiled_config (always after di:compile), and full_page (always for frontend changes). After a database schema change (setup:upgrade): also clean db_ddl and eav. You rarely need to flush all Magento 2 cache types at once — selective cleaning is faster and avoids session disruption for logged-in customers.

How do I create a custom Magento 2 cache type?

Declare the cache type in etc/cache.xml with a name, label, and instance class. Create the instance class extending MagentoFrameworkCacheFrontendDecoratorTagScope. In your service classes, inject CacheInterface and use it with the cache type name as the tag when saving data. Use the type name in bin/magento cache:clean calls for selective invalidation of your custom Magento 2 cache type.

How do I configure Redis for Magento 2 cache types?

Add Redis cache backend configuration to app/etc/env.php. Configure two separate Redis instances: one for default and page_cache, another for sessions. Set separate databases (db: 0, 1, 2) within the same Redis instance if running on a single server. Set compress_data to 1 for the page cache to reduce Redis memory usage. Adjust max_concurrency, read_timeout, and retry_reads_on_fail for production Redis Magento 2 cache type reliability.

How do I invalidate a custom Magento 2 cache type programmatically?

Inject MagentoFrameworkAppCacheInterface and call $this->cache->clean([MagentoFrameworkCacheFrontendInterface::CLEANING_MODE_MATCHING_TAG], [‘your_cache_type_name’]). Alternatively inject the cache type class directly and call clean() on it. In event observers, listen to clean_cache_by_tags or clean_cache_after_reindex events to trigger cache invalidation when related data changes in your Magento 2 cache type.

Need Magento 2 Performance Optimisation?

CodeAtoZ optimises Magento 2 cache configuration — Redis setup, Varnish VCL, selective invalidation strategy, and custom cache types for faster store performance.

CodeAtoZ
Lead Engineer & Founder, CodeAtoZ

10+ years building Magento 2 and WooCommerce platforms for high-volume e-commerce businesses. Writes about performance engineering, plugin architecture, and scalable commerce systems.

Join the Discussion

Your email address will not be published. Required fields are marked *