> What if the geoip lookup took 1.5 seconds to look up from a remote API? Is ETS still the right choice? I would use ETS to cache local lookups (for all cores

> What if the geoip lookup took 1.5 seconds to look up from a remote API? Is ETS still the right choice? I would use ETS to cache local lookups (for all cores in the same node). Then fallback to Redis to populate the ETS cache. But again, feel free to skip one of ETS or Redis. The point is that ETS adds a different tool you may (or may not) use. > Like, if I wanted to cache a PostgreSQL query that took 1 second to finish. Isn't ETS the primary place for such a thing? Here is the math you need to consider. Let's say you have M machines with N cores each. Then remember that: 1. ETS is local lookup 2. Redis is distributed lookup If you cache the data in memory in Ruby/Python, you will have to request this data in PostgreSQL M * N times to fill in all of the caches, one per core per node. Given the amount of queries, I will most likely resort to Redis. In Elixir, if you store the data in ETS, which is shared across all cores, you will have to do only M lookups. If I am running two or three nodes in production, then I am not going to bother to run Redis because having two or three different machines populating their own cache is not an issue I would worry about. > > if I need distributed state, I just use to the database too. Apologies, I meant to say "persistent distributed state" as not all distributed state is equal. For ephemeral distributed state, like Phoenix Presence and Phoenix PubSub, there is no need for storage, as they are about what is happening on the cluster right now.