<!--IssueSummary start--> <details> <summary> Everyone can contribute. [Help move this issue forward](https://handbook.gitlab.com/handbook/marketing/developer-relations/contributor-success/community-contributors-workflows/#contributor-links) while earning points, leveling up and collecting rewards. </summary> - [Close this issue](https://contributors.gitlab.com/manage-issue?action=close&projectId=278964&issueIid=562093) </details> <!--IssueSummary end--> We are reaching out from the ~"section::tenant scale" ~devops::runtime, and we have noticed a problematic Unique index `index_users_on_static_object_token` on the `users` table. As part of [Protocells](https://gitlab.com/groups/gitlab-com/gl-infra/-/epics/1616), we need to ensure that this index is still unique. With multiple GitLab instances and separate databases, this unique index will no longer be unique and may cause issues when data needs to be transferred between cells or when cluster-wide uniqueness is required but cannot be enforced by the index. For all the unique indexes, we have the following options: ## Options for Resolution ### Option A: Scope Down the Index 🔧 - Update the index to include the `sharding_key` ({"id"=>"users"}) as one of the columns - This ensures the constraint works within each cell's scope - Most common solution for indexes that can be scoped to organizational boundaries - **When to choose**: If the uniqueness can be maintained within the cell boundary ### Option B: Claim the Index 🏷️ - If any column in the index is claimed through the Topology Service, it ensures global uniqueness - Suitable when one of the indexed columns needs cluster-wide uniqueness enforcement - Requires integration with the [Claim Service](https://handbook.gitlab.com/handbook/engineering/architecture/design-documents/cells/topology_service/#claim-service) - **When to choose**: If global uniqueness across all cells is required; example `username`, `email`, etc. ### Option C: Do After Protocells ⏳ - Defer this index until after Protocells implementation - Suitable for indexes on columns with low collision probability (UUIDs, tokens, etc.) - Can be addressed in a later phase due to built-in randomness - **When to choose**: If the column has sufficient entropy to avoid conflicts ## Index Details - **Schema:** `gitlab_main_user` - **Table:** `users` - **Index Name:** `index_users_on_static_object_token` - **Index Columns:** `["static_object_token"]` - **Sharding Key:** `{"id"=>"users"}` ## Current Analysis **Decision from our analysis:** Do nothing / Claim **Notes:** We'll be claiming user details ## Next Steps Please review the options above and choose the most appropriate approach for this index: - [ ] **Option A**: Scope down the index (add sharding key to columns) - [ ] **Option B**: Claim the index (use Topology Service) - [ ] **Option C**: Do after Protocells (defer due to low collision risk) ## Resources - [Epic #18840: Cells Database UNIQUE indexes](https://gitlab.com/groups/gitlab-org/-/epics/18840) - [Cells Architecture Design](https://handbook.gitlab.com/handbook/engineering/architecture/design-documents/cells/) - [Topology Service Documentation](https://handbook.gitlab.com/handbook/engineering/architecture/design-documents/cells/topology_service/) - [Protocells Epic](https://gitlab.com/groups/gitlab-com/gl-infra/-/epics/1616) ## Questions? If you have any questions about these options or need clarification on the cells architecture requirements, please feel free to reach out to us in [#f_protocells](https://gitlab.enterprise.slack.com/archives/C0609EXHX6F) or comment on this issue.