Kafka Auxiliary Database Event Workflow Diagnostics

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Apache Kafka's event streaming platform faces challenges in dynamic multi-workflow environments, particularly in handling diverse data processing and consumption requirements across different consumers, lacking the ability to track disparate workflows and generate customizable diagnostics.

Innovation Solution

A multi-dimensional database system built on the Apache Kafka framework, incorporating an auxiliary database and computer code that tags and logs event profiles with timestamps, unique IDs, event types, and workflow identifiers, allowing for customizable workflow diagnostics based on linked data from both Kafka and the auxiliary database.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Productivity

If Apache Kafka is used for event streaming, then high-throughput and low-latency data handling is achieved, but the system lacks the ability to track disparate workflows and generate customizable diagnostics

Engineering Contradiction:
Improvedata handling throughputVSAvoidworkflow tracking capability
Core Design Contradiction:
ProductivityVSAdaptability or versatility

Solution Approach 1:

The system segments data storage and processing into two distinct components: Apache Kafka handles high-throughput event streaming, while an auxiliary database stores structured workflow metadata. This segmentation allows each component to optimize for its specific function while collectively providing both high throughput and workflow tracking capabilities

Inventive Principle:
Principle #1Segmentation

Solution Approach 2:

Event identification codes serve as intermediaries that link events in the Kafka stream to their corresponding workflow metadata in the auxiliary database. This intermediary mechanism enables the system to track disparate workflows by providing a reference system that connects real-time event data with structured workflow information

Inventive Principle:
Principle #24Intermediary (Mediator)

2Speed

If Apache Kafka is used for event streaming, then real-time data feeds are handled efficiently, but different consumers cannot easily receive data in different ways

Engineering Contradiction:
Improvereal-time data processing speedVSAvoidconsumer data processing flexibility
Core Design Contradiction:
SpeedVSAdaptability or versatility

Solution Approach 1:

The system implements dynamic workflow configurations that allow consumers to subscribe to specific workflows and receive data in customized formats. Consumers can dynamically filter, transform, and process event streams based on their specific needs while maintaining real-time processing speeds through the Kafka framework

Inventive Principle:
Principle #15Dynamics

Solution Approach 2:

The auxiliary database stores workflow parameters and consumer preferences that define how different consumers process data. By changing these parameters dynamically, the system allows each consumer to receive and process data in their preferred manner while maintaining the high-speed real-time feed from Kafka

Inventive Principle:
Principle #35Parameter changes

3Productivity

If event data is stored only in Apache Kafka, then high-throughput logging is maintained, but data linking and diagnostic generation become difficult

Engineering Contradiction:
Improveevent logging throughputVSAvoidworkflow context information
Core Design Contradiction:
ProductivityVSLoss of information

Solution Approach 1:

The system segments information storage into Kafka for raw event logging and an auxiliary database for structured workflow metadata. This segmentation preserves high logging throughput in Kafka while preventing information loss by storing contextual workflow data separately in the auxiliary database

Inventive Principle:
Principle #1Segmentation

Solution Approach 2:

Event identification codes act as intermediaries that link raw event data in Kafka with structured workflow information in the auxiliary database. This linking mechanism prevents information loss by providing a reliable connection between event logs and their contextual workflow data, enabling comprehensive diagnostic generation

Inventive Principle:
Principle #24Intermediary (Mediator)

Data Source

PatentUS11822519B2Multi-dimensional database platform including an apache kafka framework and an auxiliary database for event data processing and provisioning
Publication Date: 2023.11.21 BANK OF AMERICA CORP
  • US11822519B2 patent drawing
  • US11822519B2 patent drawing
  • US11822519B2 patent drawing

AI summary

Systems and methods for event data processing and provisioning using a multi-dimensional database platform including an Apache Kafka framework and an auxiliary database are provided. Methods may include receiving an event profile from a data producer module, tagging the event profile with a timestamp, a unique event identification code, an event type descriptor, a data producer identifier, and a workflow identifier. The method may also include logging, in the Apache Kafka framework, the timestamp and the event identification code, as part of a sequential stream of events; and storing, in the auxiliary database, the event identification code, the event type descriptor, the data producer identifier, and the workflow identifier. The method may include receiving a request from a data consumer module for a customized workflow diagnostic and generating the customized workflow diagnostic based on the specification and on data from the Apache Kafka framework and the auxiliary database as linked via the event identification code. The method may also include transmitting the customized workflow diagnostic to the data consumer module.