On second thought, I may not even need cluster-wide rate limiting. Each serve URL is already HMAC-signed and contains a valid-until timestamp. That means: expired URLs are automatically rejected, and replays outside the window can't pass. So I could just accept impressions/clicks within that short validity window, tolerate duplicates there and rely on probabilistic aggregation downstream for analytics like HLL. This would keep the system much simpler and avoid gossip/tombstone overhead altogether.
Still, it seems interesting to experiment with adding a DData-based limiter on top, just to see how far the shard+rotate pattern can go. Even if it's not essential, it could be a good case study of DData feasibility under high-churn keys.

I'm experimenting with a dedicated project that uses JMH to see how it goes. I will share it when I am done, if anyone is interested.

It's just a simulation harness to see how a DData-based rate limiter could work in practice.
The goal is to observe denial patterns and cleanup behavior.

https://github.com/hanishi/ddata-limiter-simulation

What about Bloom filter based rate limiter? The idea is to implement a distributed rate-limiter and replay-guard without keeping explicit counters, but instead by windowing with Bloom filters: each shard entity manages a current and previous time window, recording whether a given nonce has been seen; if it appears again in the same window it is denied, and anything older than the previous window is automatically rejected. This approach makes grants/denials a function of time-bucketed membership rather than precise counting, and it scales cleanly across a cluster. To survive shard passivation or rebalancing, each entity periodically publishes a compact Bloom snapshot into Pekko DData, so that a new incarnation can immediately warm-start with the recent windows instead of forgetting its history. The result is a fast, memory-efficient limiter that tolerates rebalances and skew while providing strong deduplication semantics. Each shard manages a disjoint partition of the input key-space (e.g., part = crc32(key) % parts) and therefore holds the dedup state only for its slice.

[WIP]
https://github.com/hanishi/ddata-limiter-simulation/blob/main/modules/limiter-core/src/main/scala/com/example/bloom/WindowedBloomReplayGuard.scala

You can test it with this!
https://github.com/hanishi/ddata-limiter-simulation/blob/main/modules/limiter-simulation/src/main/scala/com/example/bloom/WindowedBloomReplayGuardDriver.scala