<!-- triage-serverless v3 PLEASE DO NOT REMOVE THIS SECTION --> *This page may contain information related to upcoming products, features and functionality. It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes. Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab Inc.* <!-- triage-serverless v3 PLEASE DO NOT REMOVE THIS SECTION --> ## Summary GitLab's SaaS platform continues to grow. Our current efforts focus on [decomposing our database](https://gitlab.com/groups/gitlab-org/-/epics/6168) to improve availability. Decomposition is a vertical scaling strategy and it can only deliver a limited amount of scalability. In order to support growth beyond X M active users GitLab needs a long term horizontal scalability strategy. A Cells architecture allows for horizontal scalability and has other possible benefits, such as improved service availability. This architecture creates many mostly isolated GitLab instances, called Cells, that include all required services (database, web, Redis, Gitaly, Runners, Sidekiq etc.). The number of Cells can grow alongside the growth of the business. Sharding provides an alternative but is really hard as a universal solution. We'll end up requiring a Cells approach either way. By transitioning from Decomposition to Cells, we don’t need to find a sharding solution and avoid a “worst of all worlds” scenario where we have Decomposition, Sharding and Cells. ## Problems to solve - Scaling beyond X M active users - Improved service availability (reduced blast radius) - Eventually supporting Regions - Similar or lower cost to GitLab.com now - Compatibility with self-managed customers ## Solution **Blueprint:** https://docs.gitlab.com/ee/architecture/blueprints/cells/ **[INTERNAL Proposal presentation](https://docs.google.com/presentation/d/1x1uIiN8FR9fhL7pzFh9juHOVcSxEY7d2_q4uiKKGD44/edit#slide=id.gf92cc7c67d_3_6)** GitLab Cells is the ability to use a different set of infrastructure for a set of customers, providing key benefits: ### Design overview Very high level overview:  ### Benefits * Scalability through virtually unlimited horizontal scaling * Resilience by reducing blast radius of some outage classes * Consistent user experience by reducing “noisy neighbor” challenges * Federation features, depending on implementation, could link not only Cells but also Self-managed to itself and to GitLab.com. This is an increasingly requested request, and potential Ultimate feature. ### Potential drawbacks * Complexity * A method is required to quickly handle global user-related information * No cross-cell workflows; will require federation * We may need to maintain thousands of Cells with highly available components. That is a lot to maintain. ### Cell examples * [Shopify Pod](https://docs.google.com/presentation/d/1x1uIiN8FR9fhL7pzFh9juHOVcSxEY7d2_q4uiKKGD44/edit#slide=id.gf5b6c1cf77_2_12) * XXX ## Iteration strategy Cells is a large effort, changing the foundation of both GitLab.com’s infrastructure as well as impacting a large number of cross-namespace features and workflows. This will be a large project, and iteration will be critical to its success. **Iteration goals** * Small iterations which can be merged into main frequently * Iterations should be utilized once merged, not sitting dormant and only exercised in CI * Iterations should provide incremental value * Additional scalability * Reduced blast radius, etc. ### POCs TBD ## Testing ## Alternatives - Sharding of all components, including the database