Distributed Service Request Handling Using Time Allotment

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

In IoT systems, distributed computing can introduce significant latency due to ongoing processing of requests, even when results are no longer needed, leading to resource inefficiency and delayed responses.

Innovation Solution

Implementing a system where services determine whether to continue or fail requests based on allotted time and processing time, allowing for quick failure and retry of requests, thereby optimizing resource usage and reducing latency.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Reliability

If distributed services continue processing requests, then processing completeness may be improved, but latency increases and computing resources are wasted

Engineering Contradiction:
Improveprocessing completenessVSAvoidlatency
Core Design Contradiction:
ReliabilityVSLoss of time

Solution Approach 1:

The patent applies preliminary action by establishing timeout values and monitoring processing time before the distributed service processing is complete. The system proactively determines whether to continue or fail requests based on predicted processing time and allotted time, preventing unnecessary continued processing that would increase latency and waste resources while maintaining processing completeness when time permits

Inventive Principle:
Principle #10Preliminary action

Solution Approach 2:

The patent implements dynamics by making the request processing state flexible and adaptive. The system dynamically transitions between continuing and failing requests based on real-time conditions (actual processing time versus allotted time), allowing the processing behavior to adapt to changing system conditions rather than following a fixed processing path

Inventive Principle:
Principle #15Dynamics

2Reliability

If distributed services continue processing requests, then processing thoroughness may be improved, but computing resource availability deteriorates

Engineering Contradiction:
Improveprocessing thoroughnessVSAvoidcomputing resource availability
Core Design Contradiction:
ReliabilityVSProductivity

Solution Approach 1:

The system performs preliminary assessment of processing time requirements and compares them against allotted time before committing computing resources to complete processing. This preliminary action allows the system to avoid allocating resources to requests that cannot be completed within their time constraints, thereby preserving computing resource availability while maintaining thoroughness for requests that can be completed

Inventive Principle:
Principle #10Preliminary action

Solution Approach 2:

The patent applies discarding and recovering by abandoning (failing) requests that exceed their allotted processing time. This allows computing resources to be recovered and made available for other requests, preventing resource exhaustion while maintaining processing thoroughness for requests that can be completed within their time budgets

Inventive Principle:
Principle #34Discarding and recovering

Data Source

PatentUS11665110B1Using distributed services to continue or fail requests based on determining allotted time and processing time
Publication Date: 2023.05.30 AMAZON TECH INC
  • US11665110B1 patent drawing
  • US11665110B1 patent drawing
  • US11665110B1 patent drawing

AI summary

After a service receives a request from another service, the service determines an amount of time to process the request by the service as well as a remaining time allotment to complete processing the request (e.g., a timeout value). Based on the remaining time allotment and the amount of time to process the request by at least the service (predicted time or actual time), the service may determine whether to continue processing the request (e.g., by the service and/or one or more subsequent services) or fail the request. In response, the service may then continue processing the request (e.g., continue processing at the service itself or propagate the request to the next service), or the service may fail the request.