[cleanup] 🔥 Infinispan feature

[alexsnaps]

This isn't distributed in our binaries and Infinispan supports a Redis API that probably should be used instead of the REST client that is currently used in our implementation

[andrewdavidmackenzie]

Just my 2cents. The main reason to add infinispan originally, wasn't just optics from our "sponsor" :-) but a way to prove (and then maintain) that our data model and API didn't become intimately tied to redis, and make it virtually impossible to move away from redis in the future. i.e. architectural neutrality to the data store primitives. In 3scale backend ended up depending entirely on a number of redis data structures (e.g. ordered sets, and others) and some primitives (e.g. atomic increment, top of an ordered set, etc).

So, while not being tied to infinispan, I would argue to keep the goal of independance, and if an alternative implementation with different structs and operations is not the way to do it, come up with another one that will avoid redis leaking into our internal code.

[alexsnaps]

That independence is already provided by the existing InMemoryStorage, the RocksDbStorage and the upcoming DistributedInMemoryStorage… We're decoupling ourselves more and more from Redis in that regards… fundamentally, the InMemoryStorage is the wasm one on steroids… i.e. wasm is "only" single threaded, while the InMemoryStorage is thread safe and concurrent. Which are all of the implementation we test as part of the integration tests

[andrewdavidmackenzie]

That sounds perfect!