Approximately 20 MB of memory is reserved for all custom caches on each application server. A B2C Commerce instance can have multiple application servers, but custom caches on different application servers within the same instance are separate and not synchronized across the instance.
A common use case is to cache information that is expensive to calculate. For example, let's suppose that in your storefront, the appearance of a base product depends on the attributes of all its variation products. If any variation product is part of a promotion, the base product displays an On Sale banner. Iterating through all variation products to check whether they are part of a promotion is an expensive operation that you don't want to repeat every time the base product is displayed, but the information can't be persisted because it could change. A good workaround is to calculate the information and add it to a custom cache for a few minutes.
Another common use case is to cache responses from an external system. For example, in-store availability and prices can be stored on an external system. Instead of making a call to the system every time you need the information, cache the information for a period of time, reducing the number of calls and page load time.
You can also use a custom cache to enable fast access to configuration settings from storefront requests. To implement a configuration-as-code approach, you can retrieve configuration data from an arbritrary source, such as a JSON file from a versioning system, and store that data in a custom cache.