Skip to main content
Enterprise

Overview

The cache is designed to improve the performance of record retrieval in a Kafka by caching records. It intercepts produce and fetch requests, caching produced records and serving fetched records from the cache, if available.

Benefits

Benefits include:
  • Improved performance. By serving fetched records from the cache, subsequent fetch requests can be served faster, reducing the overall latency and improving the response time for clients.
  • Reduced load on Kafka cluster. With the cache Interceptor in place, the Kafka cluster experiences reduced load during fetch requests since a portion of the requests can be satisfied from the cache directly, reducing the number of requests hitting the cluster.
  • Enhanced scalability. The cache Interceptor provides an additional layer of scalability by distributing the workload between the cache and the Kafka cluster. It can handle a higher volume of fetch requests without overwhelming the Kafka cluster.

How the cache works

  • Produced and fetched records both fill the cache. Gateway caches records after a successful produce (except with acks=0), and caches records the cluster returns for fetch requests that miss the cache.
  • Cache entries are keyed by service account name. Within a Virtual Cluster, Gateway doesn’t serve records cached for one service account to another.
  • Transactions bypass the cache. Gateway doesn’t cache transactional produce requests and doesn’t serve read_committed fetch requests from the cache.
  • Errors aren’t cached. Gateway only caches responses without errors.

Consumer offsets

The cache Interceptor doesn’t intercept offset commit or offset fetch requests. Group membership, rebalances and offset commits go to the Kafka cluster unchanged, including for consumers served from the cache.

Configuration options

CacheConfig

RocksdbConfig

InMemConfig

Example