[ronjouch]

Interesting but not surprising; I'm being regularly pleasantly surprised by the Erlang/Elixir ecosystem :) . Can you precise what you're talking about when you say "Erlang/Elixir have built-in caches" ?

What's the name of the concept and where in the typical stack does it fit? Is this https://blog.appsignal.com/2019/11/12/caching-with-elixir-an... or something else? Care to share a few link to docs/articles? Thanks.

[pdimitar]

Yes, ETS is the usual go-to but there's also `:persistent_term`[0] for very rare (or never) changing caches.

There are libraries that combine Erlang/Elixir's caching mechanisms in an attempt to achieve the best performance for most scenarios[1] as well.

Technically, ETS is not perfect because it copies data from its mutable cache to the process that requests it. But it's still orders of magnitude faster than outsourcing that to Redis.

[0] http://erlang.org/doc/man/persistent_term.html

[1] https://github.com/gyson/ane

[ronjouch]

Thanks!

I read in http://erlang.org/doc/man/ets.html that "Each table is created by a process. When the process terminates, the table is automatically destroyed. Every table has access rights set at creation."

-> So, caching is local to each worker node/process? Do nodes/processes communicate between them to synchronize their respective caches, or is it local by design?

If local by design, that wouldn't exactly cover the use case of "Redis in front of an army of $other_language workers", correct? And I guess it's accepted as costing slightly more cache misses, but with the benefit of more decentralization / node independence / resiliency, right?

[pdimitar]

Oops, I forgot to include the most important link[0].

> If local by design, that wouldn't exactly cover the use case of "Redis in front of an army of $other_language workers", correct? And I guess it's accepted as costing slightly more cache misses, but with the benefit of more decentralization / node independence / resiliency, right?

Yes and yes.

Erlang/Elixir don't strive to make distributed caches. I wrote apps that have been scaled to 5 separate servers and each server has their own local cache (running inside the Erlang BEAM VM). Takes a little more time to warm the caches up on restarts but it has never been an issue so far.

The ETS tables ownership is trivial to hand out to another process if the owner dies (look for the "heir" option in ETS docs) but libraries like Cachex (linked at the bottom) and Ane (linked in my previous comment) wrap the ownership worries away from you.

What's left for you is just an uber-performant cache.

Do take a look at Cachex. It's hassle-free and just works.

[0] https://github.com/whitfin/cachex

[ronjouch]

Thanks again for the extra info and links :)

> "Erlang/Elixir don't strive to make distributed caches. I've wrote apps that have been scaled to 5 separate servers and each server has their own cache. Takes a little more to warm the caches up on restarts but it has never been an issue so far."

Yeah that's what I figured, makes total sense. Got into exactly the same thinking designing a circuit breaker at work. Better to let individual nodes do their own circuit breaking rather than introduce state, the complexity savings largely exceed the small cost of a little extra time needed to circuit break.