Multi-Tenant Data Staging for Asynchronous Revenue Database Updates

Resolve Bottlenecks,
Find Innovative SolutionsGenerate Solutions

Solution Overview

Problem

In multi-tenant systems, existing methods for staging data updates between different database systems, such as booking, billing, and revenue databases, suffer from bottlenecks due to heavy transformation logic, synchronous processes, and potential data inconsistencies, which hinder efficiency and violate accounting principles like ASC 606, restricting the revenue database system from performing other tasks.

Innovation Solution

A staging system that extracts a subset of relevant fields from booking and/or billing updates, maps them to specific records in the revenue database system in near real-time, and pushes these updates asynchronously, allowing the revenue database system to perform other workflows while ensuring data consistency and compliance with accounting principles.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Loss of information

If the revenue database system pulls data from booking and billing database systems, then data can be obtained, but heavy transformation logic is required and the process is synchronous

Engineering Contradiction:

Improvedata completenessVSAvoidtransformation logic complexity

Core Design Contradiction:

Loss of informationVSDevice complexity

Solution Approach 1:

A staging system is introduced as an intermediary component between the booking/billing database systems and the revenue database system. This staging system extracts data from the source systems, performs transformation, and pushes the transformed data to the revenue database system. This mediator approach eliminates the need for the revenue database system to directly pull and transform data, thereby reducing transformation logic complexity while maintaining data completeness.

Inventive Principle:

Principle #24Intermediary (Mediator)

Solution Approach 2:

The traditional pull model is inverted to a push model. Instead of the revenue database system actively pulling data from booking and billing systems, the staging system actively pushes transformed data to the revenue database system. This inversion changes the data flow direction and eliminates the synchronous dependency, allowing the revenue database system to perform other tasks independently.

Inventive Principle:

Principle #13The other way round (Inversion)

2Loss of information

If the revenue database system pulls data from booking and billing database systems, then data can be obtained, but more data is pulled than necessary

Engineering Contradiction:

Improvedata completenessVSAvoiddata volume efficiency

Core Design Contradiction:

Loss of informationVSLoss of substance

Solution Approach 1:

The staging system extracts only the necessary fields and records from the booking and billing database systems based on predefined mappings to the revenue database system schema. This selective extraction approach ensures that only relevant data is transformed and pushed, avoiding the unnecessary transfer of excess data while maintaining the required data completeness for revenue recognition operations.

Inventive Principle:

Principle #2Taking out (Extraction)

3Loss of information

If the revenue database system pulls data synchronously, then data can be obtained, but the system cannot perform other workflow tasks

Engineering Contradiction:

Improvedata availabilityVSAvoidsystem efficiency

Core Design Contradiction:

Loss of informationVSProductivity

Solution Approach 1:

The synchronous pull model is inverted to an asynchronous push model. The staging system pushes data to the revenue database system without requiring the revenue system to actively request it. This inversion eliminates the synchronous blocking behavior, allowing the revenue database system to perform other workflow tasks independently while still receiving necessary data updates through the asynchronous push mechanism.

Inventive Principle:

Principle #13The other way round (Inversion)

4Adaptability or versatility

If the revenue database system performs both revenue recognition and booking generation, then functionality is integrated, but accounting principles are violated

Engineering Contradiction:

Improvesystem functionalityVSAvoidaccounting principle compliance

Core Design Contradiction:

Adaptability or versatilityVSReliability

Solution Approach 1:

The system is segmented into distinct functional components: the staging system handles data extraction and transformation from booking/billing systems, while the revenue database system focuses solely on revenue recognition. This segmentation separates the booking generation function (in the staging system) from the revenue recognition function (in the revenue database system), thereby maintaining compliance with accounting principles like ASC 606 while preserving integrated functionality through the coordinated interaction between components.

Inventive Principle:

Principle #1Segmentation

Data Source

PatentUS12619630B2Systems and methods for staging of data updates to database system in a multi-tenant system

Publication Date: 2026.05.05 ZUORA INC

AI summary

The multi-tenant system includes one or more hardware processors that extract standard fields from one or more objects stored in source database systems, the standard fields defining standard subscription attributes. The hardware processors map the standard fields to records within a destination database system, obtain customized fields defining tenant-selected subscription attributes, obtain a mapping of the customized fields to the records; append the standard fields to the customized fields to form appended fields; schedule a pipeline to ingest the appended fields into the records within the destination database system, and ingest the appended fields into the records within the destination database system in order to stage the appended fields into the destination database system.