Event Processing System with Exponential Back-Off Retry

Resolve Bottlenecks,
Find Innovative SolutionsGenerate Solutions

Solution Overview

Problem

Traditional mobile app eventing systems face issues with reliably processing events, handling unprocessed events, preventing resource exhaustion, and adapting to new events, leading to disrupted processing and inefficiencies.

Innovation Solution

An event processing system that includes a transceiver, memory, and processor configured to retrieve, parse, and store events via an API, with notifications using exponential back-off and random jitter for subsequent processing prompts, ensuring efficient event handling and adaptation.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Reliability

If traditional mobile app eventing systems are used, then the system structure is simple, but the reliability of event processing deteriorates due to inability to handle unprocessed events and resource exhaustion

Engineering Contradiction:

Improveevent processing reliabilityVSAvoidsystem complexity

Core Design Contradiction:

ReliabilityVSDevice complexity

Solution Approach 1:

The event processing system is segmented into distinct functional modules: event reception module, event storage module, event processing module, and retry management module. This segmentation allows each module to handle specific tasks independently, improving reliability without creating a monolithic complex system.

Inventive Principle:

Principle #1Segmentation

Solution Approach 2:

The system performs preliminary actions by storing events in a persistent database before processing them. This ensures that events are preserved even if the application closes or crashes, preventing data loss and enabling reliable retry mechanisms without requiring complex real-time processing infrastructure.

Inventive Principle:

Principle #10Preliminary action

2Productivity

If events are continuously pushed to users, then event delivery completeness is improved, but resource exhaustion occurs and processing is disrupted

Engineering Contradiction:

Improveevent delivery throughputVSAvoidresource exhaustion

Core Design Contradiction:

ProductivityVSLoss of energy

Solution Approach 1:

The system implements periodic action through exponential backoff retry mechanisms. Instead of continuously pushing events, the system attempts to deliver events at increasing intervals (e.g., 1 minute, 5 minutes, 30 minutes, 2 hours) after failures, reducing resource consumption while maintaining event delivery completeness.

Inventive Principle:

Principle #19Periodic action

Solution Approach 2:

The retry interval is made dynamic through exponential backoff, where the waiting period between retry attempts increases exponentially based on the number of previous failures. This dynamic adjustment optimizes resource usage by reducing retry frequency over time while still ensuring event delivery.

Inventive Principle:

Principle #15Dynamics

3Adaptability or versatility

If new clients are continuously added to the system, then system adaptability is improved, but existing clients experience processing disruptions

Engineering Contradiction:

Improveclient scalabilityVSAvoidevent processing stability

Core Design Contradiction:

Adaptability or versatilityVSReliability

Solution Approach 1:

Each client has an isolated event processing queue and retry mechanism. When new clients are added, their events are handled independently without affecting existing clients' processing. This segmentation ensures system adaptability while maintaining processing stability for all clients.

Inventive Principle:

Principle #1Segmentation

Solution Approach 2:

The system creates independent copies of event processing contexts for each client. Each client's events, storage, and retry logic are replicated separately, allowing the system to scale to new clients without disrupting existing processing operations.

Inventive Principle:

Principle #26Copying

4Speed

If events are processed immediately upon receipt, then processing speed is improved, but events may be lost when applications close or disconnect

Engineering Contradiction:

Improveevent processing speedVSAvoidevent processing completeness

Core Design Contradiction:

SpeedVSReliability

Solution Approach 1:

The system performs preliminary storage of events in a persistent database immediately upon receipt, before processing them. This preliminary action ensures events are not lost even if the application closes or disconnects, while processing can occur at appropriate speeds without data loss risk.

Inventive Principle:

Principle #10Preliminary action

Solution Approach 2:

A persistent database acts as an intermediary between event reception and event processing. Events are first stored in this intermediary storage layer, which preserves them indefinitely, allowing processing to occur at optimal speeds without risking event loss due to application state changes.

Inventive Principle:

Principle #24Intermediary (Mediator)

Data Source

PatentUS12192309B2Eventing systems and methods to facilitate robust event processing

Publication Date: 2025.01.07 QUANATA LLC

AI summary

A device for facilitating event processing is presented. The device includes a transceiver, one or more memories including an event processing model, and one or more processors. The processors retrieve a new event from an application programming interface (API). The processors then parse the new event to determine a parsed event and store the parsed event in the memories. After determining the presence or absence of an additional new event via the API, the processors transmit a notification for display to a user indicating the parsed event and prompting a user to process the parsed event, resulting in either a successful or a failure processing signal. Responsive to receiving a failure processing signal, the processors schedule a subsequent notification for transmission to the user device according to an event processing model by using an exponential back-off and a random jitter.