# US 2023/0054871 A1 · Systems and methods for processing of messages subject to dead letter queues in representational state transfer architectures to prevent data loss in cloud-based computing environments

> Agents: this data is available as JSON from the patentgrep API and MCP server — see https://patentgrep.com/llms.txt

- Number: US 2023/0054871 A1
- Document ID: US20230054871A1
- Status: Published application
- Kind: A1
- Application number: 17/407,635
- Filed: 2021-08-20
- Published: 2023-02-23
- Earliest claimed: 2021-08-20
- Assignees: Capital One Services, LLC
- Applicants: Capital One Services, LLC
- Inventors: Shitij Kulshreshtha; Daniel Leslie; Ik Tae Kim; Piyush Mohan
- Web page: https://patentgrep.com/patent/US20230054871A1

## CPC

- G06F 11/0709: {in a distributed system consisting of a plurality of standalone computer nodes, e.g. clusters, client-server systems}
- G06F 11/076: {by exceeding a count or rate limit, e.g. word- or bit count limit}
- G06F 9/45512: {Command shells}
- G06F 9/542: {Event management; Broadcasting; Multicasting; Notifications}
- G06F 9/547: {Remote procedure calls [RPC]; Web services}
- G06F 11/0751: {Error or fault detection not based on redundancy (power supply failures G06F1/30; network fault management H04L41/06)}
- G06F 11/0787: {Storage of error reports, e.g. persistent data storage, storage using memory protection}
- G06F 11/0793: {Remedial or corrective actions (recovery from an exception in an instruction pipeline G06F9/3861; by retry G06F11/1402; for recovering from a failure of a protocol instance or entity H04L69/40)}
- G06F 8/36: Software reuse
- G06F: ELECTRIC DIGITAL DATA PROCESSING (computer systems based on specific computational models G06N)

## Abstract

Systems and methods are provided for processing of messages subject to dead letter queues in representational state transfer (“REST”) architectures to prevent data loss in cloud-based environments. For example, as opposed to conventional RESTful application programming interface (“API”) approaches to handling message failures, the systems and methods provide a new system component to handle these failures. Specifically, instead of relying on a conventional dead letter queue (e.g., requiring a system to read the queue via lambda functions), the systems and methods create a representative system file based on any REST call in which a failure is detected.

## Claims

### Claim 1

A system for improved processing of messages subject to dead letter queues in representational state transfer (“REST”) architecture to prevent data loss in cloud-based computing environments through dynamic file creation without a need for independent storage of the messages, the system comprising:
cloud-based dedicated memory; and
cloud-based control circuitry configured to:
receive a REST call;
compare the REST call to a system parameter;
determine a failure of the REST call based on comparing the REST call to the system parameter;
determine whether the failure corresponds to a first failure type or a second failure type based upon a system parameter type of the system parameter to which the REST call was compared, wherein the first failure type requires manual review, and wherein the second failure type does not require manual review;
determine to generate a representative system file based on the REST call in response to determining that the failure corresponds to the first failure type; and
determine not to generate the representative system file based on the REST call in response to determining that the failure corresponds to the second failure type;
generate the representative system file based on the REST call in response to determining the failure, wherein the representative system file includes a characteristic of the REST call;
store the representative system file in the dedicated memory;
retrieve the representative system file from the dedicated memory, wherein the representative system file is retrieved from the dedicated memory based on a configuration file that specifies shell commands to run periodically on a given schedule;
process the representative system file, wherein the representative system file is processed using a serverless compute service that runs code without managing servers, creating workload-aware cluster scaling logic, maintaining event integrations, or managing runtimes;
determine a failure response for the REST call based on processing the representative system file;
transmit the failure response in response to determining the failure response for the REST call based on processing the representative system file; and
delete the representative system file from the dedicated memory.

### Claim 2

A method for improved processing of messages subject to dead letter queues in representational state transfer (“REST”) architecture through dynamic file creation without a need for independent storage of the messages, the method comprising:
receiving a REST call;
comparing the REST call to a system parameter;
determining a failure of the REST call based on comparing the REST call to the system parameter;
in response to determining the failure, generating a representative system file based on the REST call, wherein the representative system file includes a characteristic of the REST call;
storing the representative system file in dedicated memory;
retrieving the representative system file from the dedicated memory;
processing the representative system file; and
determining a failure response for the REST call based on processing the representative system file.

### Claim 3 (depends on 2)

The method of claim 2, wherein determining the failure of the REST call based on comparing the REST call to the system parameter comprises:
determining that a queue to which the REST call is directed does not correspond to the system parameter, wherein the system parameter corresponds to a known system queue;
determining that a length of the queue to which the REST call is directed exceeds the system parameter, wherein the system parameter is a queue length limit;
determining that the REST call is expired based on the system parameter, wherein the system parameter is a per-message time to live; or
determining that a message length of the REST call exceeds the system parameter, wherein the system parameter is a message length limit.

### Claim 4 (depends on 2)

The method of claim 2, further comprising:
determining whether the failure corresponds to a first failure type or a second failure type based upon a system parameter type of the system parameter to which the REST call was compared, wherein the first failure type requires manual review, and wherein the second failure type does not require manual review;
in response to determining that the failure corresponds to the first failure type, determining to generate the representative system file based on the REST call; and
in response to determining that the failure corresponds to the second failure type, determining not to generate the representative system file based on the REST call.

### Claim 5 (depends on 2)

The method of claim 2, further comprising:
in response to determining the failure response for the REST call based on processing the representative system file, transmitting the failure response; and
deleting the representative system file from the dedicated memory.

### Claim 6 (depends on 2)

The method of claim 2, further comprising:
receiving a user input indicating a frequency at which to process the representative system file; and
determining to process the representative system file at the frequency.

### Claim 7 (depends on 2)

The method of claim 2, further comprising:
generating a modified REST call based on the failure response; and
transmitting the modified REST call.

### Claim 8 (depends on 7)

The method of claim 7, further comprising:
determining a number of attempts for processing the modified REST call based on a response time for addressing failures of a first failure type; and
processing the modified REST call based on the number of attempts.

### Claim 9 (depends on 8)

The method of claim 8, further comprising:
determining that the modified REST call has been processed the number of attempts; and
in response to determining that the modified REST call has been processed the determined number of attempts, determining that the failure corresponds to the first failure type, wherein the first failure type requires manual review.

### Claim 10 (depends on 2)

The method of claim 2, wherein the representative system file is processed using a serverless compute service that runs code without managing servers, creating workload-aware cluster scaling logic, maintaining event integrations, or managing runtimes.

### Claim 11 (depends on 2)

The method of claim 2, wherein the representative system file is retrieved from the dedicated memory based on a configuration file that specifies shell commands to run periodically on a given schedule.

### Claim 12

A non-transitory, computer-readable medium for improved processing of messages subject to dead letter queues in representational state transfer (“REST”) architecture through dynamic file creation without a need for independent storage of the messages, comprising instructions that, when executed by one or more processors, cause operations comprising:
determining a failure of a REST call based on comparing the REST call to a system parameter;
generating a representative system file based on the REST call in response to determining the failure, wherein the representative system file includes a characteristic of the REST call;
storing the representative system file in dedicated memory;
retrieving the representative system file from the dedicated memory, wherein the representative system file is retrieved from the dedicated memory based on a configuration file that specifies shell commands to run periodically on a given schedule;
processing the representative system file, wherein the representative system file is processed using a serverless compute service that runs code without managing servers, creating workload-aware cluster scaling logic, maintaining event integrations, or managing runtimes; and
determining a failure response for the REST call based on processing the representative system file.

### Claim 13 (depends on 12)

The non-transitory, computer-readable medium of claim 12, wherein determining the failure of the REST call based on comparing the REST call to the system parameter comprises:
determining that a queue to which the REST call is directed does not correspond to the system parameter, wherein the system parameter corresponds to a known system queue;
determining that a length of the queue to which the REST call is directed exceeds the system parameter, wherein the system parameter is a queue length limit;
determining that the REST call is expired based on the system parameter, wherein the system parameter is a per-message time to live; or
determining that a message length of the REST call exceeds the system parameter, wherein the system parameter is a message length limit.

### Claim 14 (depends on 12)

The non-transitory, computer-readable medium of claim 12, wherein the instructions further cause operations comprising:
determining whether the failure corresponds to a first failure type or a second failure type based upon a system parameter type of the system parameter to which the REST call was compared, wherein the first failure type requires manual review, and wherein the second failure type does not require manual review;
in response to determining that the failure corresponds to the first failure type, determining to generate the representative system file based on the REST call; and
in response to determining that the failure corresponds to the second failure type, determining not to generate the representative system file based on the REST call.

### Claim 15 (depends on 12)

The non-transitory, computer-readable medium of claim 12, wherein the instructions further cause operations comprising:
in response to determining the failure response for the REST call based on processing the representative system file, transmitting the failure response; and
deleting the representative system file from the dedicated memory.

### Claim 16 (depends on 12)

The non-transitory, computer-readable medium of claim 12, further comprising:
receiving a user input indicating a frequency at which to process the representative system file; and
determining to process the representative system file at the frequency.

### Claim 17 (depends on 12)

The non-transitory, computer-readable medium of claim 12, wherein the instructions further cause operations comprising:
generating a modified REST call based on the failure response; and
transmitting the modified REST call.

### Claim 18 (depends on 17)

The non-transitory, computer-readable medium of claim 17, wherein the instructions further cause operations comprising:
determining a number of attempts for processing the modified REST call based on a response time for addressing failures of a first failure type; and
processing the modified REST call based on the number of attempts.

### Claim 19 (depends on 18)

The non-transitory, computer-readable medium of claim 18, wherein the instructions further cause operations comprising:
determining that the modified REST call has been processed the number of attempts; and
in response to determining that the modified REST call has been processed the number of attempts, determining that the failure corresponds to the first failure type, wherein the first failure type requires manual review.

### Claim 20 (depends on 12)

The non-transitory, computer-readable medium of claim 12, wherein the instructions further cause operations comprising:
receiving the REST call; and
comparing the REST call to the system parameter.