And yeah if you can cache the response for even like a second it may help quite a bit. Cachex provides a nice built in ttl feature that will automatically bust your cache after a set timeframe.
chasers
chulkilee
Okay then you have N+1 query problem - this is data fetching problem not necessarily elixir.
You may make it faster by performing N+1 queries in parallel (use Task for instance) - but in this case you loose the benefit of Redis pipelining.
Anyway you’re accessing the data not in “Redis way”. You may prefetch most values if knows the pattern in advance - e.g. using SCAN or it’s family.
Or you can use Lua script to preprocess a little bit on redis side.
As you have redis, you may use redis for caching as well - which is helpful if transformation is expensive compared to network bandwidth between erlang nodes and redis instance.
2
codeRaider
I don’t know if cache the cached data is correctly 
I try to make clean this process, but situations like this, I think is required to storage on memory the data if is concurrent its use to use quick (Redis data could be a backup data). The problem is when this data is updated, change or delete. The process will be processed in Redis and Cache in paralelle (Like Sync data).
0
fsa
I know very little about this topic - but before doing any code changes or system alterations - check if the increase in the size of the data being processed is causing swaps to disks anywhere… just a thought 
0