One reason would be that doing that would require switching over to cgo, at which point you deal with the PITA that is an FFI, and the PITA that is cgo (it's easy to enable but it drastically alters your "game plan").

And here the cache is essentially the entirety of the micro-service:

> [The service's] sole purpose is to keep track of which channels and messages you have read.

so it's a giant map of (user, object) -> read flag or something along those lines. The DB commit and service input would be very light, and not really your main concern.

The question I’d have is “why use a custom cache at all”, this sounds like a problem that has a whole pile of battle-tested off-the-shelf solutions.

The original implementation of this "service" was in Redis using lua scripts.

We hit the performance ceiling of redis, and rather than deciding to go with redis-cluster, and dealing with the headache of managing persistent redis, we went this way, so we could consolidate data storage to scylladb/cassandra (it was cassandra at the time of rewrite, scylla now since we've migrated our data stores over).

any reason to not consider Aerospike for Cache?

We don't have any operational experience with Aerospike.

We have a bunch of operational experience with C*/ScyllaDB.

That sounds like basically what they did; they rewrote the ReadStates service in Rust and it sounds like that's basically a wrapper around an LRU cache. The rest of Discord is still Go/Elixer/whatever else they use.