# 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 first phase of work of the Orders re-architecture. In this phase, the focus is on the foundational work: - Moving the existing `Zuora::*` classes to `Zuora::Remote::*` - Creating the database tables for the Zuora cache data - Building the new Zuora cache data models - Setting up appropriate validations - Setting up auditing ## 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/)