Surely a SQL query with SELECT, COUNT and GROUP would be simpler (and give you all counts for the given user in one go). It would also be faster to implement reliably, faster to run, more scalable and more maintainable.
This solution requires an extra instance of Redis in addition to a SQL db (which I assume is already in the mix), and has the potential for consistency drift.
For a very large database where the count would be filtered based on status of the conversations and running this query for every single support channel would be expensive would it not?
Given that the SQL approach is the standard one, I'd personally expect load testing to demonstrate that it didn't scale before doing something unusual.
This solution requires an extra instance of Redis in addition to a SQL db (which I assume is already in the mix), and has the potential for consistency drift.
And SQL is a very close cousin of set theory.