I was just thinking, future EOM modules may also rely on Redis. What if a deployer wants to use the same Redis instance for multiple modules? Or, what if a deployer wants to use different Redis instances for different modules?

In the first case, we may run into key name collisions. However, I think we can cross that bridge when we come to it, since these counters are ephemeral and we can easily rename them later, if needed (YAGNI).

In the second case, the config group name appears to be generic to all EOM middleware; renaming this later would be a bit of pain, since we would have to maintain backwards-compat with old config files. With that in mind, we might try renaming the group to something more specific, such as "eom:governor:redis". But if we did that, redis_pool would no longer be "generic". The way to fix that, I suppose, would be to move the config options definitions to the governor, and then pass in the alread-loaded config group into ```get_client```.

Another option would be to just put these settings under the existing "eom:governor" group, prefixing each option with "redis_" or using a single setting and providing a "connection URI" such as "redis://some-host.example.com:6379".

That do you think?

BTW, I think it would be helpful in any case to set defaults for host and port to localhost:6379.