You can still use redis for caching here, people use usually cachex to avoid adding external dependencies and having network latency (that a lot of time defeats the propose of having cache in the first place).

As for the limit, since the caching is part of the runtime from where you are running the app (and sharing the memory), I don’t think a feature that would limit memory usage would make much sense, moreover I don’t think this can be reliably measured from within the application code (where cachex operates from).

It cannot, specifically taking into account that the Erlang VM is smart enough to not duplicate the memory for the same objects.

t1 = {1, 2}
m1 = %{a: t1}
m2 = %{a: t1}
:erts_debug.same(m1.a, m2.a)
#⇒ true

Also :erts_debug – being a debug tool – doesn’t include data on the shared binary heap as well, being asked for size of a term.

Answering the question stated, partitioning the data per expected size and starting several Cachex.start/2 instances with different limits, one per each “size range” would do.