Revisit redis & cache:clear strategy

[eduarguz]

There are some facts that have already been recommended before:

You should use different redis databases for each application

but also..

You should use different redis databases for each "store", meaning, (default, cache, session, jobs?, app-metrics?, broadcasting? etc)...

Why?
Because when you run php artisan cache:clear the whole database will be "flushed" and that might not be known by many developers, meaning that probably some apps are losing their redis data more frequently that what they would want.

The solution is already given: use different databases per app, per store. And that is the recommendation.

A new problem:

When using Laravel Vapor you get to easily connect your app to AWS ElastiCache Redis clusters in the matter of just a few clicks which is awesome but comes with a new problem... When you are using clusters, there is only one redis database available (Database 0) meaning that you can't use 15 different redis databases for each app or store unless you are very clear of the implications of the "cache:clear" command are.

Just wanted to share the facts that I found after having this issue with many apps that share the same cluster and after wanting to move my sessions to redis driver which will result in your users sessions being lost after any cache:clear command has been executed.

• Is there a better way to approach this?
• Should we have a more specific way to clear cache stores even if they are in the same redis database/cluster?
• Should that be better documented so users know the implications?
• What would you do with vapor? cluster per app per store

Happy to hear your thoughts or suggestions ✌️

Related:
#29349 (comment)
#5034
laravel/laravel#4665
#20655
#32744