DRI: @lmcandrew ## Why functional partitioning? We have [decided](https://gitlab.com/gitlab-com/gl-infra/scalability/-/issues/1986) that we will use Redis Cluster https://gitlab.com/groups/gitlab-com/gl-infra/-/epics/823 as our long-term _horizontal_ scaling strategy for Redis. However, it is unclear when this will be production-ready. In the meanwhile, there are workloads running on Redis Sentinel (single master node) that are predicted to saturate in the near future. The most reliable and predictable approach we have to avoid saturation is through _functional partitioning_ - freeing up capacity by moving specific workloads to their own instance. **The purpose of this epic** is to organize the various partitioning options that have been discussed. If saturation forecasts become a critical concern, the appropriate option should be promoted to its own project and worked on, similar to https://gitlab.com/groups/gitlab-com/gl-infra/-/epics/857.