Questions about distributed cache

[sjoshi-liveperson]

1. Bucket4J supports various platforms to store the distributed cache like JVM based Hazelcast and Non JVM alternatives like Redis.

Bucket4J documentation says: Bucket4j authors strongly recommends to use JVM based back-ends when possible, but for cases where it is not possible Bucket4j provides following integrations with non-JVM based storages.

Q: Can someone call out the top reasons for this recommendation? ( I am guessing it is for the performance, but exactly in what area?)

2. For Sharing the Rate Limiting state among multiple server nodes there are mainly two streategies, 1. Distributed Cache and 2. Local cache with gossip protocol to communicate in-between the server notdes to sync-up on consumed tokens. In option2, we lose accuracy and achieve low latency.

Q: I am guessing all the options discussed and supported by Bucket4J are of Option 1. Am I correct?

[vladimir-bukhtoyarov]

Hello @sjoshi-liveperson

Bucket4J documentation says: Bucket4j authors strongly recommends to use JVM based back-ends when possible, but for cases where it is not possible Bucket4j provides following integrations with non-JVM based storages.
Q: Can someone call out the top reasons for this recommendation? ( I am guessing it is for the performance, but exactly in what area?)

JVM based in-memory solutions provide support for concept called EntryProcessors. Utilizing this feature by Bucket4j allows to make remote requests faster. Redis/Tarantool has similar cocept called as Lua Stored procedures, but this functionality has not adopted yet by Bucket4j, that is why JVM based backeds will always faster.

For Sharing the Rate Limiting state among multiple server nodes there are mainly two streategies, 1. Distributed Cache and 2. Local cache with gossip protocol to communicate in-between the server notdes to sync-up on consumed tokens. In option2, we lose accuracy and achieve low latency.
Q: I am guessing all the options discussed and supported by Bucket4J are of Option 1. Am I correct?

A some sort of second variant is supported too. There are varios optimizations strategies that should be used when contention on the bucket is high. Version 8.2.RC1 alse includes optimization that allows bucket to work fully authonomouslly until explicit synchronization requested #326 (reply in thread)