←back to thread

The Evolution of Caching Libraries in Go

(maypok86.github.io)
127 points maypok86 | 1 comments | 29 Jun 25 17:07 UTC | HN request time: 0.223s | source
Show context
regecks ◴[02 Jul 25 19:47 UTC] No.44448030[source]▶
We’re looking for a distributed Go cache.

We don’t want to round trip to a network endpoint in the ideal path, but we run multiple instances of our monolith and we want a shared cache tier for efficiency.

Any architecture/library recommendations?

replies(8): >>44448526 #>>44448621 #>>44449247 #>>44449260 #>>44449523 #>>44450156 #>>44450474 #>>44450952 #
1. nchmy ◴[02 Jul 25 22:29 UTC] No.44449523[source]▶
perhaps a NATS server colocated on each monolith server (or even embedded in your app, if it is written in golang, meaning that all communication is in-process) and use NATS KV?

Or if you just want it all to be in-memory, perhaps use some other non-distributed caching library and do the replication via NATS? Im sure there's lots of gotchas with something like that, but Marmot is an example of doing SQLite replication via NATS Jetstream

edit: actually, you can set jetstream/kv to be in-memory rather than file persistence. So, it could do the job of olric or rolling your own distributed kv via nats. https://docs.nats.io/nats-concepts/jetstream/streams#storage...