Dynamic Schema Registry for API Data Reporting

Resolve Bottlenecks,
Find Innovative SolutionsGenerate Solutions

Solution Overview

Problem

Conventional API architectures struggle to handle large volumes of diverse data types from various sources, requiring downtime for incremental changes and failing to support dynamic data schema adjustments at runtime, which limits their ability to serve changing user demands for different data types and processing modes.

Innovation Solution

A self-adjusting API architecture using dynamic data schema that allows for runtime changes without code modifications, supporting both streaming and batch processing, and handling bi-temporal data, enabling seamless integration with multiple data sources and client devices through a declarative-type system and GraphQL-based query processing.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Adaptability or versatility

If conventional API architecture is used to handle large volumes of diverse data types, then data processing capability is limited, but system complexity and downtime for changes increase

Engineering Contradiction:

Improvedata type handling capabilityVSAvoidsystem complexity

Core Design Contradiction:

Adaptability or versatilityVSDevice complexity

Solution Approach 1:

The patent implements a dynamic schema registry that allows data schemas to be registered, updated, and evolved at runtime without requiring system downtime or code changes. The schema registry dynamically adapts to new data types and structures, enabling the API architecture to handle diverse data types flexibly while maintaining system stability.

Inventive Principle:

Principle #15Dynamics

Solution Approach 2:

The patent creates a universal data contract framework that can accommodate multiple data types, sources, and processing modes (streaming and batch) through a single unified architecture. The schema-validated data processing pipeline serves as a multi-functional component that handles various data formats and processing requirements without requiring separate specialized systems.

Inventive Principle:

Principle #6Universality (Multi-functionality)

2Reliability

If incremental changes are made to conventional API architecture, then existing functionality is maintained, but system downtime occurs and adaptability to new data types is reduced

Engineering Contradiction:

Improvesystem availabilityVSAvoidruntime schema adjustment capability

Core Design Contradiction:

ReliabilityVSAdaptability or versatility

Solution Approach 1:

The patent implements schema validation and registration mechanisms that prepare the system in advance for new data types. The schema registry pre-defines data contracts and validation rules, allowing the system to adapt to new data types seamlessly when they arrive, without requiring downtime or disruptive changes to existing functionality.

Inventive Principle:

Principle #10Preliminary action

Solution Approach 2:

The patent ensures continuous system operation by implementing a schema-validated data processing pipeline that can handle new data types and schema changes without interruption. The system maintains continuous data processing capability while dynamically adapting schemas at runtime, eliminating downtime associated with traditional incremental changes.

Inventive Principle:

Principle #20Continuity of useful action

3Productivity

If static data schema is used in conventional API architecture, then data processing is simpler, but responsiveness to changing user demands for different data types is reduced

Engineering Contradiction:

Improvedata processing efficiencyVSAvoidresponse to changing data demands

Core Design Contradiction:

ProductivityVSAdaptability or versatility

Solution Approach 1:

The patent replaces static data schemas with dynamic schemas that can evolve at runtime based on user demands and new data types. The schema registry allows schemas to be registered, updated, and validated dynamically, enabling the system to respond flexibly to changing data requirements while maintaining processing efficiency through schema validation.

Inventive Principle:

Principle #15Dynamics

4Adaptability or versatility

If conventional API architecture supports multiple data sources, then data diversity increases, but integration complexity and processing overhead increase

Engineering Contradiction:

Improvemulti-source data integrationVSAvoidintegration complexity

Core Design Contradiction:

Adaptability or versatilityVSDevice complexity

Solution Approach 1:

The patent implements a universal data contract framework that provides a single unified interface for integrating multiple data sources. The schema-validated processing pipeline serves as a multi-functional component that handles various data formats, sources, and processing modes through consistent validation and transformation mechanisms, reducing integration complexity while supporting data diversity.

Inventive Principle:

Principle #6Universality (Multi-functionality)

Data Source

PatentUS20240345997A1Data reporting architecture for applications

Publication Date: 2024.10.17 THE TORONTO DOMINION BANK

AI summary

One example method includes receiving a request from a client application for data of a particular data type. In response to receiving the request, it is determined that a schema corresponding to the particular data type is unavailable at a server. In response to the determination, a new schema for the particular data type and a new schema definition including the new schema are generated, wherein the new schema was not previously known to the server. Data corresponding to the particular data type are obtained from one or more data sources, and the obtained data along with the generated new schema are forwarded to the client application.