# Cache management for rate limiting/throttling

**URL:** <https://forums.pega.com/t/cache-management-for-rate-limiting-throttling/12667>\
**Category:** Pega-as-a-Service\
**Tags:** performance, pega-platform\
**Created:** [July 8, 2026, 1:28pm UTC](https://forums.pega.com/t/cache-management-for-rate-limiting-throttling/12667 "2026-07-08T13:28:16Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![DennisA69](https://yyz2.discourse-cdn.com/pega/user_avatar/forums.pega.com/dennisa69/32/273_2.png) [@DennisA69](https://forums.pega.com/u/DennisA69)\
**Post date:** [July 8, 2026, 1:28pm UTC](https://forums.pega.com/t/cache-management-for-rate-limiting-throttling/12667/1 "2026-07-08T13:28:16Z")

</div>

We have an application that uses Bucket4j for throttling with Hazelcast as the backing in-memory data grid cache. Since Hazelcast is no longer supported as of Pega Infinity '25, we are looking for throttling on a low-latency caching solution that works across multiple (preferably on) specified node types. The release notes at [Platform '25 release notes](https://docs.pega.com/bundle/platform-25/page/platform/release-notes/platform-release-notes.html#rn-platform-release-notes-parent-con__dl_ejd_jnq_mgc) mention Pega provides built-in alternatives. How can we use these built-in alternatives?

---

<div class="post-metadata">

**Author:** ![aniki](https://yyz2.discourse-cdn.com/pega/user_avatar/forums.pega.com/aniki/32/23301_2.png) [@aniki](https://forums.pega.com/u/aniki)\
**Post date:** [July 20, 2026, 12:55pm UTC](https://forums.pega.com/t/cache-management-for-rate-limiting-throttling/12667/2 "2026-07-20T12:55:13Z")

</div>

Hi @DennisA69 , there isn’t a like-for-like distributed in-memory cache to re-point Bucket4j at. Everything Hazelcast used to do is now handled by Pega natively (Kafka-backed cache sync, node-local caching with DB-backed coordination, Kubernetes for node discovery), but it doesn’t mean that Pega provides these capabilities to the outside consumer natively.

Probably the closest platform-native replacement for a custom token bucket is a dedicated Queue Processor. You can control throughput by limiting consumers/threads and pinning it to a specific node type — this gives you a predictable, cluster-wide TPS ceiling without any shared in-memory counter.

Another advantage it gives you is more compatibility with Pega Cloud, which can make migration much easier.