Reactive Mono-Service Framework for High-Volume Transaction Processing

Resolve Bottlenecks,
Find Innovative SolutionsGenerate Solutions

Solution Overview

Problem

Current transaction processing systems face challenges in handling high-volume, low-latency transactions efficiently, particularly in electronic payment systems, where complex procedures and varying processing rules for different contract providers and transaction types lead to inefficiencies.

Innovation Solution

The implementation of a reactive programming framework that uses configurable, small, easily testable units of code called mono-services, which are function literals with defined inputs and outputs, executed in a sequence or concurrently, to process transactions quickly and flexibly across different contract providers and networks.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Productivity

If traditional transaction processing systems are used, then they can handle various transaction types, but they cannot achieve high-volume, low-latency processing

Engineering Contradiction:

Improvetransaction processing volumeVSAvoidprocessing latency

Core Design Contradiction:

ProductivityVSLoss of time

Solution Approach 1:

The system segments transaction processing into independent, stateless function literals (mono-services) that can be executed in parallel. Each function literal handles a specific transaction step, enabling high-volume processing through concurrent execution while maintaining low latency. This is achieved by breaking down complex transaction procedures into small, easily testable units of code that can be distributed and executed independently.

Inventive Principle:

Principle #1Segmentation

2Adaptability or versatility

If complex procedures are implemented for different contract providers, then various transaction types can be processed, but system complexity increases

Engineering Contradiction:

Improvecontract provider compatibilityVSAvoidprocessing system complexity

Core Design Contradiction:

Adaptability or versatilityVSDevice complexity

Solution Approach 1:

The system implements a universal contract provider interface that works across different transaction types and providers. The reactive programming framework provides a unified mechanism for loading and executing function literals, making the system adaptable to various contract providers without increasing complexity. Each contract provider is handled through the same standardized interface, allowing versatility while maintaining simplicity.

Inventive Principle:

Principle #6Universality (Multi-functionality)

Solution Approach 2:

The system manages complexity by dynamically loading different function literals based on transaction parameters such as contract provider type. Instead of hardcoding complex procedures for each provider, the system changes execution parameters by selecting and loading appropriate function literals at runtime, enabling adaptability without structural complexity.

Inventive Principle:

Principle #35Parameter changes

3Ease of manufacture

If traditional monolithic code structures are used, then implementation is straightforward, but testing and error handling become difficult

Engineering Contradiction:

Improvecode implementation easeVSAvoiderror handling and testing ease

Core Design Contradiction:

Ease of manufactureVSEase of repair

Solution Approach 1:

The system divides code into small, isolated function literals that are independently testable and easily replaceable. Each function literal represents a discrete unit of transaction processing logic, making it simple to implement individual functions while enabling comprehensive testing and error handling. The segmentation allows developers to test and repair specific functions without affecting the entire system.

Inventive Principle:

Principle #1Segmentation

4Reliability

If location-specific processing is implemented, then local requirements can be met, but the system loses scalability and responsiveness

Engineering Contradiction:

Improvelocal requirement complianceVSAvoidsystem scalability

Core Design Contradiction:

ReliabilityVSProductivity

Solution Approach 1:

The system implements location-agnostic processing through a universal reactive programming framework that can execute the same function literals across different locations and contract providers. The framework provides consistent error handling, transaction management, and execution mechanisms that work uniformly regardless of location, enabling scalability while meeting local requirements through configurable function literal selection rather than location-specific code.

Inventive Principle:

Principle #6Universality (Multi-functionality)

Data Source

PatentUS12099998B2Configurable, reactive architecture framework for data stream manipulation at scale

Publication Date: 2024.09.24 JPMORGAN CHASE BANK NA

AI summary

Various methods, apparatuses, and media for processing a transaction are provided. A request to process the transaction is received. The request includes a plurality of pieces of transaction data. An initial contract is identified, based on at least a first piece of the transaction data, and loaded. The initial contract includes a plurality of mono-services, with each of the mono-services being a function literal that includes a defined input and output and being configured to implement exactly one piece of functionality. The initial contract is executed, with the mono-services being configured to return a result for responding to the request to process the transaction.