# Background The Fulfillment section has an initiative to https://gitlab.com/groups/gitlab-org/-/epics/9748+. The Orders model in CDot is misleading and prone to data accuracy issues. Given these problems, we are pursuing a new data architecture for CDot to meet several objectives shown below. - Increase the accuracy of CustomersDot data pertaining to Subscriptions and its entitlements. This data is currently stored as `Order` records in CustomersDot which has been error prone as shown by the following issues: - [Multiple order records for the same subscription](https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/6971) - [Multiple subscriptions active for the same namespace](https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/6972) - [Support Multiple Active Orders on a Namespace](https://gitlab.com/groups/gitlab-org/-/epics/9486) - Continue to align with Zuora Billing being the SSoT for Subscription and Order data. - Decrease dependency and reliance on Zuora Billing uptime. - Improve CustomersDot performance by storing relevant Subscription data locally and keeping it in sync with Zuora Billing. This could be a key piece to making Seat Link more efficient and reliable. More information about this work, including full technical plan, can be found in the [architecture blueprint](https://docs.gitlab.com/ee/architecture/blueprints/cdot_orders/). # Purpose This epic covers the third phase of work of the Orders re-architecture. In this phase, the focus is utilizing the new Zuora cache data models. There are many places in CustomersDot where Zuora is queried for Subscription, Rate Plan, Rate Plan Charge, or Rate Plan Charge Tier data. In the places where CDot is reading from Zuora, we should consider replacing them with queries to the local cache data models instead. This should be a big performance boost by avoiding third party requests, particularly in components like the Seat Link Service. In previous phases, we moved the remove resource models to the `Zuora::Remote` namespace (e.g. `Zuora::Remote::Subscription`). The local Zuora models were created under the namespace `Zuora::Local` namespace (e.g. `Zuora::Local::Subscription`). In this phase, we will create interface classes like `Zuora::Subscription`. These models will be agnostic to how the data should be fetched; whether from remote or local. This will be determined based on a feature flag logic contained in these interface classes. This will make it easier for engineers as the feature flag logic can live in one class (or a set of classes) rather than scattered throughout the application. ## Resources - [Orders Proposal](https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/main/doc/architecture/orders_proposal.md) - [Orders Architecture Blueprint](https://docs.gitlab.com/ee/architecture/blueprints/cdot_orders/)