How do Redis ACLs (Redis 6+) improve on the single-password model?

You need to give a specific client read‑only access to a subset of keys in Redis. How would you configure an ACL to achieve that, and what command would the client use to authenticate?

If you add a new user with a password but forget to assign any command categories, what will happen when the client tries to run a GET command?

Your team migrated from Redis 5 to Redis 6 and started seeing authentication failures for some services. Walk me through how you would debug whether the issue is due to ACL misconfiguration versus password changes.

We want to limit a background worker to only execute EVALSHA and a few hash commands. Explain how you would set up the ACL and what trade‑offs you consider regarding command categories versus explicit command lists.

Design a strategy for rolling out ACLs across a large fleet of microservices that currently share a single password, ensuring zero downtime and minimal risk of lock‑out.

At high scale, how do ACL checks impact Redis performance, and what mitigations would you put in place if you notice latency spikes after enabling fine‑grained ACLs?

Our organization is moving from a monolithic Redis instance with a single password to a multi‑tenant architecture with per‑tenant ACLs. Discuss the architectural changes, migration plan, and how you would handle legacy clients that cannot be updated immediately.

Consider a scenario where multiple teams need to share a Redis cluster but enforce strict data isolation. How would you use ACLs together with other Redis features (e.g., key‑space notifications, namespaces) to provide a secure, maintainable solution at scale?