Transaction Middleware Replication for Dynamic Financial Processing Capacity
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Existing financial transaction processing systems struggle to dynamically adjust their size in response to demand fluctuations and often require complex deployments that impact other system entities when changes are introduced.
Innovation Solution
A system is configured to process financial transactions by maintaining TM sub-modules, modules, and super-modules on a first server, allowing for dynamic replication of TM super-modules to a second or third server based on demand, using a cloud infrastructure monitoring system like Kubernetes to manage resource allocation.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Adaptability or versatility
If a fixed number of communication channels is allocated for authorization requests, then system simplicity is maintained, but the system cannot adapt to varying transaction volumes and may become a bottleneck during high-volume periods
Solution Approach 1:
The patent implements dynamic sizing of the authorization request queue, allowing the queue capacity to be adjusted based on current transaction volume and system conditions. This enables the system to adapt to varying loads without requiring a fixed, oversized queue that would complicate the system architecture.
Solution Approach 2:
The system changes the parameter of queue size dynamically based on transaction volume metrics. By adjusting this parameter rather than maintaining a fixed value, the system achieves adaptability while keeping the underlying queue mechanism simple and well-understood.
2Productivity
If a large number of communication channels are provisioned to handle peak transaction volumes, then system capacity is improved, but resource utilization efficiency decreases during low-volume periods
Solution Approach 1:
The queue size is made dynamic rather than static, allowing the system to optimize resource utilization by adjusting capacity to match actual demand. This prevents waste of communication resources during low-volume periods while maintaining sufficient capacity during peak periods.
Solution Approach 2:
The system changes the operational parameter of queue size based on observed transaction patterns and system performance, achieving optimal productivity without permanently provisioning excessive resources that would reduce overall efficiency.
3Reliability
If synchronization mechanisms are added to ensure thread-safe access to shared queue data, then data consistency is improved, but processing speed decreases due to locking overhead
Solution Approach 1:
The patent implements segmentation by creating separate queue instances for different threads or processes, eliminating the need for complex synchronization mechanisms. Each thread operates on its own queue copy, achieving data consistency without locking overhead that would reduce processing speed.
Solution Approach 2:
Instead of having multiple threads access and modify a single shared queue (requiring synchronization), the system creates copies of the queue data structure for different threads. This copying approach maintains data consistency while avoiding the performance penalty of synchronization primitives.
Data Source
Figure 1
Figure 2~4
Figure 5
AI summary
A system for processing a financial transaction request and a method executed by the system can include receiving, at a first server, a request to execute the financial transaction request. The first server can determine transaction middleware (TM) super-modules that are stored on the first server and are required to execute the financial transaction. The first server can detect capacities of the TM super-modules and annex control over memory space of a second server if needed. The first server can replicate at least one of the TM super-modules on the memory of the second server and direct the financial transaction request to the TM super-module replicated on the second server. That TM super-module can generate a corresponding output received by the first server, which can then cede control over the memory space of the second server.