Intelligent retry and traffic coordination control system and method for business api

Abstract

This invention discloses an intelligent retry and traffic coordination control system and method for commercial APIs, belonging to the field of intelligent traffic coordination control technology. The system includes: a configuration management module for configuring independent rate limiters matching the official quotas of each API endpoint; a priority scheduling module for managing multi-priority blocking queues and background worker thread pools; an adaptive rate limiting module containing adaptive rate limiters corresponding one-to-one with API types; an exception handling module containing platform-specific exception handlers and error code mappers; a retry calculation module for calculating intelligent backoff time based on the number of retries and exception types; and a monitoring and statistics module for collecting operational metrics in real time, providing data for rate adjustment by the adaptive rate limiting module and dynamic priority adjustment by the priority scheduling module. This invention achieves efficient, stable, and adaptive integration capabilities for complex commercial API ecosystems through a multi-level intelligent control mechanism.

Description

Technical Field

[0001] This invention relates to the field of intelligent traffic coordination control technology, and in particular to an intelligent retry and traffic coordination control system and method for commercial APIs. Background Technology

[0002] In today's enterprise software ecosystem, it has become standard practice for systems to exchange data by calling application programming interfaces (APIs) from third-party service providers (such as Amazon, Google, and Microsoft). Taking e-commerce as an example, merchants frequently need to call Amazon's Selling Partner API (SP-API) and Amazon Advertising API to synchronize core business data such as orders, inventory, and advertising reports.

[0003] However, in such distributed API call scenarios, the following technical pain points are common:

[0004] 1. Difficulty in Managing Differentiated API Quotas: Commercial API service providers (such as Amazon) set strict and differentiated call frequency limits for different API endpoints. For example, the Create Report API is limited to once per minute, while the Get Report API is allowed twice per second. Traditional single rate limiting strategies cannot meet this granular quota management requirement.

[0005] 2. Insufficient Adaptation to Traffic Surges on E-commerce Platforms: E-commerce platforms exhibit significant traffic surges (such as traffic spikes during promotional events). Fixed rate limiting strategies cannot adaptively adjust call frequency, resulting in wasted quotas during off-peak periods and insufficient response during peak periods.

[0006] 3. Lack of Task Priority: Different API calls in the business system have different priorities. For example, real-time transaction data synchronization has a higher priority than historical report generation. Existing retry mechanisms typically lack task priority scheduling, failing to guarantee timely responses to critical business needs.

[0007] 4. Insufficient handling of platform-specific exceptions: Different API platforms (such as Amazon SP-API and Ads API) have unique exception systems and error codes. General retry strategies cannot handle platform-specific exceptions in a refined manner, resulting in invalid retries or missed retries.

[0008] 5. Low system resource utilization: Traditional synchronous blocking retry mechanisms cause threads to wait for a long time, reducing the overall system throughput. This resource waste is particularly significant in large-scale API call scenarios.

[0009] While various retry and rate limiting schemes exist in existing technologies, there is a lack of a comprehensive solution that integrates differentiated quota management, adaptive flow control, priority scheduling, and platform-specific exception handling. Summary of the Invention

[0010] This invention aims to address at least one of the technical problems existing in the prior art. To this end, this invention proposes an intelligent retry and traffic coordination control system and method for commercial APIs, which achieves efficient, stable, and adaptive integration capabilities for complex commercial API ecosystems through a multi-level intelligent control mechanism.

[0011] One embodiment of the present invention provides an intelligent retry and traffic coordination control system for commercial APIs, comprising: a configuration management module for storing the mapping relationship between API type identifiers and rate limiting policies, configuring independent rate limiters matching their official quotas for each API endpoint, and presetting the basic priority level and division rules for API call tasks; a priority scheduling module for managing multi-priority blocking queues and background worker thread pools, encapsulating API call requests into priority tasks and adding them to the corresponding queues, scheduling task execution according to priority order, and supporting dynamic floating adjustment of the basic priority of priority tasks; and an adaptive rate limiting module containing multiple adaptive rate limiters corresponding one-to-one with API types, used to allocate call permissions to API call tasks and adjust the rate limit based on the API call success rate. The system dynamically adjusts the call rate based on statistical data, ensuring that the adjusted rate does not exceed the official rate limit of the corresponding API endpoint. An exception handling module, including platform-specific exception handlers and error code mappers, identifies the exception type and error code of the API call, distinguishes between recoverable and unrecoverable exceptions, and outputs the exception judgment result. A retry calculation module calculates the intelligent backoff time based on the number of retries and the exception type, using a differential coefficient combined with random jitter, when the exception handling module determines the exception to be recoverable. A monitoring and statistics module collects operational metrics in real time, including API call success rate, response time, number of retries, rate limiting status, and task data timeliness, providing data for the rate adjustment of the adaptive rate limiting module and the dynamic priority adjustment of the priority scheduling module.

[0012] According to some embodiments of the present invention, the dynamic priority adjustment in the priority scheduling module specifically involves, based on the operating indicators of the monitoring and statistics module, reducing the scheduling priority of medium-priority and low-priority tasks when the external API platform experiences increased rate limiting or a decrease in call success rate, and allocating resources to high-priority real-time transaction and inventory synchronization tasks; reducing the priority of the corresponding task to the lowest level and prohibiting retry scheduling when a task triggers an unrecoverable exception; and temporarily increasing the priority of the corresponding task when there is a risk of data expiration.

[0013] According to some embodiments of the present invention, the exception handler includes an Amazon SP-API exception handler and an Amazon Advertising API exception handler, which are used to parse the unique exception information of the corresponding platform and determine the recoverability of the exception by combining the error code and the response body content; the retry calculation module configures different exponential backoff coefficients for three types of recoverable exceptions: rate limit, network, and server internal, and supports adding random jitter values ​​and setting a maximum backoff time threshold.

[0014] According to some embodiments of the present invention, the priority scheduling module uses CompletableFuture to implement asynchronous non-blocking processing of API calls, and the background worker thread pool is a configurable daemon thread pool that supports tens of thousands of concurrent API calls and can avoid thread blocking and resource exhaustion.

[0015] Another embodiment of the present invention provides an intelligent retry and traffic coordination control method for commercial APIs, comprising the following steps: S100, receiving an API call request, the request including an API type identifier, a priority identifier, and business logic, wherein the priority identifier corresponds to a preset basic priority level; S200, obtaining a corresponding adaptive rate limiter from a pre-configured rate limiting mapping table according to the API type identifier, wherein the rate limiting mapping table is an independent rate limiting strategy for each API endpoint matching its official quota; S300, encapsulating the API call request into a priority task and placing it into a priority blocking queue; S400, having a background worker thread obtain priority tasks from the priority blocking queue according to priority order; S500, obtaining API call permission through the adaptive rate limiter; S6 S700: Execute the API call and monitor the call results and exception information; S800: Update the success rate statistics of the adaptive rate limiter according to the call results, and dynamically adjust the API call rate based on the statistics, ensuring that the adjusted rate does not exceed the official rate limit range of the corresponding API endpoint; S900: When the API call fails, identify the exception type and error code according to the platform's unique exception system, and determine whether the exception is a recoverable exception; S900: If it is determined to be an unrecoverable exception, directly return the exception information of the call failure; if it is determined to be a recoverable exception, calculate the intelligent backoff time based on the number of retries and the exception type, wherein the intelligent backoff time adopts a calculation method combining a differential coefficient and random jitter; S1000: Put the priority task back into the priority blocking queue, waiting for the next scheduling execution.

[0016] According to some embodiments of the present invention, the step S700 of dynamically adjusting the API call rate based on statistical data specifically includes: when the number of consecutive successes reaches a first threshold, increasing the current call rate by a first percentage, and the adjusted rate not exceeding the official maximum rate limit for the corresponding API type; when the number of consecutive failures reaches a second threshold, decreasing the current call rate by a second percentage, and the adjusted rate not lower than the official minimum rate limit for the corresponding API type; when the number of consecutive failures reaches a third threshold, aggressively decreasing the current call rate by a third percentage, wherein the third percentage is greater than the second percentage, and the adjusted rate not lower than the official minimum rate limit for the corresponding API type. According to some embodiments of the present invention, optimizing the dynamic weight fusion model through reinforcement learning includes: dynamically adjusting the decision weights of vibration data in mechanical wear faults based on historical diagnostic accuracy feedback.

[0017] According to some embodiments of the present invention, the differentiated calculation method of the intelligent backoff time in step S900 is specifically as follows: for rate limiting errors, an exponential backoff calculation is performed using a first backoff coefficient; for network errors, an exponential backoff calculation is performed using a second backoff coefficient; for server-side internal errors, an exponential backoff calculation is performed using a third backoff coefficient; wherein, the first backoff coefficient > the second backoff coefficient > the third backoff coefficient; the random jitter is a random value within the range of 0 to half of the calculation result superimposed on the exponential backoff calculation result, and the final backoff time does not exceed the preset maximum backoff time threshold.

[0018] According to some embodiments of the present invention, the step S800 of identifying the exception type and error code based on the platform-specific exception system specifically includes: if the exception is a specific exception of Amazon SP-API, determining whether it is a recoverable exception based on the returned error code and response body content; if the exception is a specific exception of Amazon Advertising API, determining whether it is a recoverable exception based on the retry flag built into the exception; if the exception is a general network exception, directly determining it as a recoverable exception; the recoverable exceptions include rate limiting errors, server-side internal errors, and general network exceptions, while unrecoverable exceptions are platform-specific business logic errors.

[0019] According to some embodiments of the present invention, the preset basic priority levels include high priority, medium priority and low priority, specifically divided as follows: high priority is API call tasks for real-time transactions and inventory synchronization; medium priority is API call tasks for order processing and report generation; low priority is API call tasks for historical data archiving and statistical calculation; the priority tasks implement a comparable interface, and are sorted by the numerical value of the priority level, with the smaller the value, the higher the priority.

[0020] According to some embodiments of the present invention, the method further includes a dynamic floating priority adjustment step: during the API call process, the API call success rate, the external API platform rate limiting status, the timeliness of task data, and the anomaly type are monitored in real time. Based on the monitoring results, the basic priority of the priority task is dynamically increased or decreased, and the background worker thread schedules tasks according to the dynamically adjusted real-time priority. The specific rules for the dynamic floating priority adjustment are as follows: when the external API platform rate limiting is increased or the overall call success rate decreases, the scheduling priority of medium-priority and low-priority tasks is automatically reduced, the execution of low-priority tasks is suspended or postponed, and API quotas and system scheduling resources are preferentially allocated to high-priority tasks; when an unrecoverable anomaly is identified in which a priority task triggers a platform-specific business logic error, the priority of the corresponding priority task is directly reduced to the lowest level, and retrying and scheduling are prohibited, releasing the occupied API quotas and system resources; when it is detected that a priority task has insufficient data timeliness or is at risk of expiration due to failure to schedule in a timely manner, the priority of the task is temporarily increased to ensure that it completes the API call within the data validity time window.

[0021] The embodiments of the present invention achieve at least the following beneficial effects:

[0022] This invention addresses core pain points in commercial API integration, such as difficulties in quota management, insufficient adaptation to tidal traffic, lack of task prioritization, rudimentary exception handling, and low resource utilization, through a multi-level collaborative design that incorporates differentiated quota management, adaptive traffic control, intelligent priority scheduling, platform-specific exception handling, and asynchronous non-blocking architecture. It addresses these issues from multiple dimensions, including technical implementation, business application, resource utilization, and operation and maintenance management. The invention achieves efficient, stable, and adaptive API call integration, while also possessing significant industrial application value. Specific beneficial effects are as follows:

[0023] 1. Achieve refined quota management, align with official platform rules, and mitigate violation risks: The example establishes a one-to-one independent rate limiter for each API endpoint, accurately matching the official quota limits of commercial API platforms. This eliminates the drawbacks of traditional single rate limiting strategies, avoiding quota waste and preventing platform rate limiting and interface bans caused by exceeding quota limits. It also supports dynamically adding new API endpoint configurations, offering strong scalability and adapting to the refined rate limiting needs of hundreds of different API endpoints.

[0024] 2. Adaptive traffic control, precisely adapting to tidal traffic, and improving quota utilization efficiency: The system's built-in intelligent adaptive rate adjustment algorithm can dynamically adjust the call rate based on API call success rate and consecutive success / failure counts, and the rate adjustment always stays within the platform's official limits; during peak traffic periods such as e-commerce promotions, the system automatically and aggressively slows down and intelligently degrades non-core businesses to ensure service stability; during off-peak periods, the rate is gradually increased to maximize the utilization of API quotas, achieving "tidal calculation," significantly improving the overall quota utilization efficiency, and accelerating data processing.

[0025] 3. Intelligent priority scheduling ensures the timeliness of core business operations and avoids resource misallocation: The system presets three basic priority levels (high, medium, and low) and strongly binds them to business operations. Core businesses such as real-time transactions and inventory synchronization are set as high priority, and priority blocking queues ensure that core tasks are executed first. At the same time, it supports dynamic floating priority adjustment. Based on the platform's rate limiting status, call success rate, task data timeliness, and exception type, the priority of tasks can be adjusted up or down in real time. When resources are scarce, quotas and scheduling resources are automatically tilted towards core businesses, preventing low-priority tasks from crowding out resources and preventing core tasks from losing value due to data expiration. This balances the protection of core businesses with the rationality of overall task scheduling.

[0026] 4. Refined handling of platform-specific exceptions to improve effective call rates and avoid unnecessary retries: The system designs dedicated exception handlers for the unique exception systems of different commercial API platforms (such as Amazon SP-API and Amazon Ads API). It can accurately identify recoverable exceptions and platform-specific business logic errors by combining error codes and response body content. Retries are only executed for recoverable exceptions such as rate limits, server errors, and general network exceptions, completely avoiding meaningless retries for business logic errors, reducing the unnecessary consumption of API quotas and system resources, and providing detailed error diagnosis information to provide a basis for troubleshooting.

[0027] 5. Asynchronous non-blocking architecture design improves system throughput and supports large-scale concurrency: The system adopts CompletableFuture and a dedicated daemon thread pool to achieve fully asynchronous non-blocking execution, avoiding the long-term waiting problem of threads caused by traditional synchronous blocking retries, greatly reducing context switching overhead, and supporting tens of thousands of large-scale concurrent API calls; the thread pool resources are controllable, which can effectively avoid thread exhaustion and significantly improve the overall throughput and processing efficiency of the system.

[0028] 6. Significantly improve API call stability and data synchronization efficiency, reducing data inconsistency issues: By combining intelligent retry, adaptive rate limiting, and refined exception handling mechanisms, the system increases the API call success rate to over 99.7%, significantly reducing data inconsistency issues caused by API call failures; at the same time, it significantly shortens data synchronization latency and reduces the number of times platform rate limiting is triggered. In actual cross-border e-commerce platform applications, data synchronization latency is reduced by 73% and the average daily number of rate limiting triggers is reduced by 98%, ensuring the real-time performance and accuracy of business data.

[0029] 7. Reduce maintenance costs, improve maintenance efficiency, and achieve automated fault recovery: The system has comprehensive automated fault handling capabilities. It can automatically recover from faults through adaptive adjustment and intelligent retries, significantly reducing the number of manual maintenance interventions. In actual applications, the average daily maintenance intervention frequency is reduced by 94%. At the same time, the system configuration is centralized and takes effect without restarting. It also has a unified monitoring and alarm system, complete call chain tracing, and rich business indicator statistics, which enhances the system's observability and makes it easier for maintenance personnel to quickly troubleshoot problems, reducing overall maintenance costs by 60%.

[0030] 8. Optimize system resource utilization and reduce resource occupancy: The system reduces the ineffective consumption of system resources from the source by prohibiting meaningless retries, dynamically scheduling resources, and allocating resources on demand based on priority; the asynchronous architecture and controllable thread pool design further improve resource utilization efficiency. In actual applications, the system CPU occupancy rate is reduced by 35%, realizing the refined and efficient utilization of system resources.

[0031] 9. Platform-friendly and highly scalable with broad industrial application value: The system always respects and adapts to the official restriction policies and exception handling systems of various commercial API platforms, with no platform intrusion and strong adaptability; at the same time, it adopts a pluggable exception handler architecture and a unified error code conversion layer, and supports dynamic configuration of API rate limiting strategies, making it easy to extend to new API types and platform adaptation. It has been practically verified on large-scale cross-border e-commerce platforms and can be widely used in e-commerce, enterprise-level software integration, and other scenarios that require calling commercial APIs, with significant industrial promotion value.

[0032] Additional aspects and advantages of the invention will be set forth in part in the description which follows, and in part will be obvious from the description, or may be learned by practice of the invention. Attached Figure Description

[0033] The above and / or additional aspects and advantages of the present invention will become apparent and readily understood from the description of the embodiments taken in conjunction with the following drawings, in which:

[0034] Figure 1 This is a schematic block diagram of the system modules according to an embodiment of the present invention;

[0035] Figure 2 This is a flowchart illustrating the method according to an embodiment of the present invention.

[0036] Figure label:

[0037] Configuration management module 100, priority scheduling module 200, adaptive rate limiting module 300, exception handling module 400, retry calculation module 500, and monitoring and statistics module 600. Detailed Implementation

[0038] Embodiments of the present invention are described in detail below. Examples of these embodiments are shown in the accompanying drawings, wherein the same or similar reference numerals denote the same or similar elements or elements having the same or similar functions throughout. The embodiments described below with reference to the accompanying drawings are exemplary and are only used to explain the present invention, and should not be construed as limiting the present invention.

[0039] In the description of this invention, "several" means one or more, "multiple" means two or more, "greater than," "less than," and "exceeding" are understood to exclude the stated number, while "above," "below," and "within" are understood to include the stated number. The use of "first" and "second" in the description is merely for distinguishing technical features and should not be construed as indicating or implying relative importance, or implicitly indicating the number of indicated technical features, or implicitly indicating the order of the indicated technical features.

[0040] Reference Figure 1 This invention proposes an intelligent retry and traffic coordination control system for commercial APIs, comprising:

[0041] The configuration management module 100 is used to store the mapping relationship between API type identifiers and rate limiting policies, configure independent rate limiters that match their official quotas for each API endpoint, and preset the basic priority level and division rules of API call tasks.

[0042] The priority scheduling module 200 is used to manage multi-priority blocking queues and background worker thread pools. It encapsulates API call requests into priority tasks and adds them to the corresponding queues. It schedules tasks to be executed in priority order and supports dynamic floating adjustment of the base priority of priority tasks.

[0043] The adaptive rate limiting module 300 contains multiple adaptive rate limiters that correspond one-to-one with the API type. It is used to allocate call permissions to API call tasks and dynamically adjust the call rate based on API call success rate statistics. The adjusted rate does not exceed the official rate limit range of the corresponding API endpoint.

[0044] The exception handling module 400 includes platform-specific exception handlers and error code mappers, which are used to identify the exception type and error code of API calls, distinguish between recoverable and unrecoverable exceptions, and output the exception judgment result.

[0045] The retry calculation module 500 is used to calculate the intelligent backoff time based on the number of retries and the type of exception when the exception handling module determines that the exception is recoverable. This is done by using a differential coefficient combined with random jitter.

[0046] The monitoring and statistics module 600 is used to collect operational metrics in real time. These metrics include API call success rate, response time, number of retries, rate limiting status, and task data timeliness, providing data basis for the rate adjustment of the adaptive rate limiting module and the dynamic priority adjustment of the priority scheduling module.

[0047] In some embodiments, the dynamic priority adjustment in the priority scheduling module specifically involves, based on the operating metrics of the monitoring and statistics module, reducing the scheduling priority of medium-priority and low-priority tasks when the external API platform experiences increased rate limiting or a decrease in call success rate, and allocating resources to high-priority real-time transaction and inventory synchronization tasks; reducing the priority of the corresponding task to the lowest level and prohibiting retry scheduling when a task triggers an unrecoverable exception; and temporarily increasing the priority of the corresponding task when there is a risk of data expiration.

[0048] In some embodiments, the exception handlers include an Amazon SP-API exception handler and an Amazon Ads API exception handler, which are used to parse the unique exception information of the corresponding platform and determine the recoverability of the exception by combining the error code and the response body content. The retry calculation module configures different exponential backoff coefficients for three types of recoverable exceptions: rate limit, network, and server internal. It also supports adding random jitter values ​​and setting a maximum backoff time threshold.

[0049] In some embodiments, the priority scheduling module uses CompletableFuture to implement asynchronous non-blocking processing of API calls, and the background worker thread pool is a configurable daemon thread pool that supports tens of thousands of concurrent API calls and can avoid thread blocking and resource exhaustion.

[0050] Reference Figure 2 This invention proposes an intelligent retry and traffic coordination control method for commercial APIs, comprising the following steps:

[0051] S100: Receive API call request. The request includes API type identifier, priority identifier and business logic. The priority identifier corresponds to the preset basic priority level.

[0052] S200. Based on the API type identifier, retrieve the corresponding adaptive rate limiter from the pre-configured rate limit mapping table. The rate limit mapping table is an independent rate limit strategy for each API endpoint that matches its official quota.

[0053] S300: Encapsulate API call requests into priority tasks and place them in a priority blocking queue;

[0054] S400: Priority tasks are retrieved from the priority blocking queue by background worker threads in priority order.

[0055] S500 obtains API call permission through an adaptive rate limiter;

[0056] S600: Execute API calls and monitor call results and exception information;

[0057] S700: Update the success rate statistics of the adaptive rate limiter based on the call results, and dynamically adjust the API call rate based on the statistics, and the adjusted rate does not exceed the official rate limit range of the corresponding API endpoint.

[0058] S800: When an API call fails, the platform-specific exception system identifies the exception type and error code to determine whether the exception is recoverable.

[0059] S900: If the exception is determined to be unrecoverable, return the exception information of the call failure directly; if the exception is determined to be recoverable, calculate the intelligent backoff time based on the number of retries and the exception type. The intelligent backoff time is calculated using a combination of differential coefficient and random jitter.

[0060] S1000: Put the priority task back into the priority blocking queue and wait for the next scheduling execution.

[0061] In some embodiments, step S700 dynamically adjusts the API call rate based on statistical data, specifically as follows: when the number of consecutive successful calls reaches a first threshold, the current call rate is increased by a first percentage, and the adjusted rate does not exceed the official maximum rate limit for the corresponding API type; when the number of consecutive failures reaches a second threshold, the current call rate is decreased by a second percentage, and the adjusted rate is not lower than the official minimum rate limit for the corresponding API type; when the number of consecutive failures reaches a third threshold, the current call rate is aggressively decreased by a third percentage, the third percentage being greater than the second percentage, and the adjusted rate is not lower than the official minimum rate limit for the corresponding API type.

[0062] In some embodiments, the differentiated calculation method of intelligent backoff time in step S900 is as follows: for rate limiting errors, an exponential backoff calculation is performed using a first backoff coefficient; for network errors, an exponential backoff calculation is performed using a second backoff coefficient; for server-side internal errors, an exponential backoff calculation is performed using a third backoff coefficient; wherein, the first backoff coefficient > the second backoff coefficient > the third backoff coefficient; random jitter is a random value within the range of 0 to half of the calculation result added to the exponential backoff calculation result, and the final backoff time does not exceed the preset maximum backoff time threshold.

[0063] In some embodiments, step S800 identifies the exception type and error code based on the platform-specific exception system. Specifically, if the exception is a specific exception of Amazon SP-API, it is determined whether it is a recoverable exception based on the returned error code and response body content; if the exception is a specific exception of Amazon Advertising API, it is determined whether it is a recoverable exception based on the retry flag built into the exception; if the exception is a general network exception, it is directly determined to be a recoverable exception; recoverable exceptions include rate limiting errors, server-side internal errors, and general network exceptions, while unrecoverable exceptions are platform-specific business logic errors.

[0064] In some embodiments, the preset basic priority levels include high priority, medium priority and low priority, specifically divided as follows: high priority is for API call tasks of real-time transaction and inventory synchronization; medium priority is for API call tasks of order processing and report generation; low priority is for API call tasks of historical data archiving and statistical calculation; priority tasks implement a comparable interface, and are sorted by the numerical value of the priority level, with the smaller the value, the higher the priority.

[0065] In some embodiments, during the API call process, the API call success rate, external API platform rate limiting status, task data timeliness and exception type are monitored in real time. Based on the monitoring results, the basic priority of priority tasks is dynamically increased or decreased, and the background worker thread schedules tasks according to the dynamically adjusted real-time priority.

[0066] In some embodiments, the specific rules for dynamic floating priority adjustment are as follows: when it is detected that the external API platform's rate limiting is becoming more severe or the overall call success rate is decreasing, the scheduling priority of medium-priority and low-priority tasks is automatically reduced, the execution of low-priority tasks is suspended or postponed, and API quotas and system scheduling resources are preferentially allocated to high-priority tasks; when it is identified that a priority task triggers an unrecoverable exception that is a platform-specific business logic error, the priority of the corresponding priority task is directly reduced to the lowest level, and retrying and scheduling of it are prohibited, releasing the occupied API quotas and system resources; when it is detected that a priority task has insufficient data timeliness or is at risk of expiration due to failure to schedule in a timely manner, the priority of the task is temporarily increased to ensure that it completes the API call within the data validity time window.

[0067] In one specific embodiment, this invention is applied to dynamic floating priority scheduling under the tidal traffic of Amazon Prime Day. A cross-border e-commerce company connects to Amazon North America's SP-API. During the Prime Day promotion, the platform's order volume surged, and Amazon's SP-API experienced global rate limiting (frequent 429 errors + QuotaExceeded response bodies). The overall API call success rate plummeted from the usual 99.7% to 58%. The company needed to ensure the core business of real-time order synchronization (P0) and inventory synchronization (P0), while also handling order processing (P1) and suspending the archiving of non-core historical sales data (P2).

[0068] According to the rules of this embodiment, Amazon SP-API's ListOrders (real-time order synchronization) and GetInventory (inventory synchronization) are set to P0 high priority, UpdateOrderStatus (order processing) is set to P1 medium priority, and GetHistoricalSales (historical data archiving) is set to P2 low priority. Each API is bound to an independent adaptive rate limiter (fitting Amazon's official quota: ListOrders once per second, GetInventory twice per second). When the monitoring and statistics module detects in real time that Amazon SP-API rate limiting has intensified and the overall call success rate has dropped to 58%, the priority scheduling module immediately executes dynamic floating rules: the priority of the P2 level GetHistoricalSales task is reduced to the lowest level and completely suspended, releasing the API quota and system thread resources it occupies; the call rate of the P1 level UpdateOrderStatus task is reduced by 60%, retaining only the processing capacity of core orders and reducing unnecessary calls; the P0 level ListOrders / GetInventory is kept at the highest priority, and all the quota and resources released by P2 / P1 are allocated to the P0 task. The adaptive rate limiting module adjusts the rate separately for the P0 task (within the Amazon official quota, the speedup ratio after consecutive successes is increased from 1.05 to 1.1 to maximize the utilization of the core quota). After the exception handling module identifies the Amazon SP-API-specific 429+QuotaExceeded exception, it performs differentiated intelligent backoff only for P0 tasks (the backoff coefficient is 3 for rate limiting errors, with random jitter added), reduces the number of retries for P1 tasks, and directly prohibits retries for P2 suspended tasks.

[0069] In another specific embodiment, this invention is applied to dynamic priority and exception coordination handling under Amazon SP-API-specific business exceptions. When an e-commerce company connects to Amazon Europe's SP-API and executes UpdateInventory (inventory deduction, P0 high priority) and CreateReport (sales report generation, P1 medium priority) tasks, some CreateReport tasks trigger Amazon-specific business exceptions (error code 400, response body contains InvalidReportType, indicating an unrecoverable business logic error, retrying is meaningless), while a small number of UpdateInventory tasks trigger Amazon 503 server-side recoverable exceptions. The exception handling module, which connects to the Amazon Europe SP-API exception system, identifies the 400+InvalidReportType-specific business exception returned by the CreateReport task, determines it as an unrecoverable exception, and immediately sends an exception signal to the priority scheduling module and the monitoring and statistics module. Upon receiving the exception signal, the priority scheduling module executes dynamic floating rules on all P1-level CreateReport tasks that triggered this specific exception: its priority is immediately reduced to the lowest level, retrying is prohibited, scheduling is immediately paused, and the API quota and thread resources occupied by this type of task are released in real time. All released resources are allocated to P0-level UpdateInventory tasks. For 503 recoverable exceptions triggered by these tasks, a smart backoff time is calculated using a server-side error-specific backoff coefficient of 1.5, and after adding random jitter, the task is rescheduled. The adaptive rate limiting module reserves the entire call quota for P0 tasks without any speed reduction. The monitoring and statistics module records the task characteristics of this unique exception and automatically adds the report type corresponding to InvalidReportType to the blacklist. Subsequent similar tasks will be directly intercepted to avoid consuming resources again.

[0070] In practice on a large cross-border e-commerce platform, the embodiments of the present invention achieved the following effects (see Table 1).

[0071] Table 1. Practical application results on a major cross-border e-commerce platform

[0072]

[0073] Compared with existing technical solutions, the embodiments of the present invention have the following advantages (see Table 2).

[0074] Table 2 Comparison of this embodiment with existing technologies

[0075]

[0076] Although specific embodiments are described herein, those skilled in the art will recognize that many other modifications or alternative embodiments are also within the scope of this disclosure. For example, any of the functions and / or processing capabilities described in connection with a particular device or component can be performed by any other device or component. Furthermore, while various exemplary embodiments and architectures have been described according to embodiments of this disclosure, those skilled in the art will recognize that many other modifications to the exemplary embodiments and architectures described herein are also within the scope of this disclosure.

[0077] The foregoing description, with reference to block diagrams and flowcharts of systems, methods, systems, and / or computer program products according to exemplary embodiments, has described certain aspects of this disclosure. It should be understood that one or more blocks in the block diagrams and flowcharts, as well as combinations of blocks in the block diagrams and flowcharts, can be implemented by executing computer-executable program instructions, respectively. Similarly, according to some embodiments, some blocks in the block diagrams and flowcharts may not need to be executed in the order shown, or may not all need to be executed. Furthermore, additional components and / or operations beyond those shown in the blocks in the block diagrams and flowcharts may exist in some embodiments.

[0078] Therefore, blocks in block diagrams and flowcharts support combinations of means for performing a specified function, combinations of elements or steps for performing a specified function, and program instruction means for performing a specified function. It should also be understood that each block in a block diagram and flowchart, and combinations of blocks in block diagrams and flowcharts, can be implemented by a dedicated hardware computer system or a combination of dedicated hardware and computer instructions that performs a specific function, element, or step.

[0079] The program modules, applications, etc., described herein may include one or more software components, including, for example, software objects, methods, data structures, etc. Each such software component may include computer-executable instructions that, in response to execution, cause at least a portion of the functionality described herein (e.g., one or more operations of the exemplary methods described herein) to be performed.

[0080] Software components can be coded using any of a variety of programming languages. An exemplary programming language could be a low-level programming language, such as assembly language associated with a specific hardware architecture and / or operating system platform. Software components including assembly language instructions may need to be converted into executable machine code by an assembler before being executed by the hardware architecture and / or platform. Another exemplary programming language could be a higher-level programming language that is portable across multiple architectures. Software components including higher-level programming languages ​​may need to be converted into an intermediate representation by an interpreter or compiler before execution. Other examples of programming languages ​​include, but are not limited to, macro languages, shell or command languages, job control languages, scripting languages, database query or search languages, or report writing languages. In one or more exemplary embodiments, a software component containing instructions from one of the above-described programming language examples can be executed directly by the operating system or other software components without first being converted into another form.

[0081] Software components can be stored as files or other data storage structures. Software components of similar type or related function can be stored together in a specific directory, folder, or library. Software components can be static (e.g., pre-defined or fixed) or dynamic (e.g., created or modified at runtime).

[0082] The embodiments of the present invention have been described in detail above with reference to the accompanying drawings. However, the present invention is not limited to the above embodiments. Within the scope of knowledge possessed by those skilled in the art, various changes can be made without departing from the spirit of the present invention.

Claims

1. A smart retry and traffic coordination control system for commercial APIs, characterized in that, include: The configuration management module is used to store the mapping relationship between API type identifiers and rate limiting policies, configure independent rate limiters for each API endpoint that match its official quota, and preset the basic priority level and division rules of API call tasks. The priority scheduling module is used to manage multi-priority blocking queues and background worker thread pools. It encapsulates API call requests into priority tasks and adds them to the corresponding queues. It schedules tasks for execution according to priority order and supports dynamic floating adjustment of the base priority of priority tasks. The adaptive rate limiting module contains multiple adaptive rate limiters that correspond one-to-one with API types. It is used to allocate call permissions to API call tasks and dynamically adjust the call rate based on API call success rate statistics. The adjusted rate does not exceed the official rate limit range of the corresponding API endpoint. The exception handling module includes platform-specific exception handlers and error code mappers, used to identify the exception type and error code of API calls, distinguish between recoverable and unrecoverable exceptions, and output the exception judgment result. The retry calculation module is used to calculate the intelligent backoff time based on the number of retries and the type of exception when the exception handling module determines that the exception is recoverable. It uses a combination of differential coefficients and random jitter to calculate the intelligent backoff time. The monitoring and statistics module is used to collect operational metrics in real time. These metrics include API call success rate, response time, number of retries, rate limiting status, and task data timeliness, providing data basis for the rate adjustment of the adaptive rate limiting module and the dynamic priority adjustment of the priority scheduling module.

2. The intelligent retry and traffic coordination control system for commercial APIs according to claim 1, characterized in that, The dynamic priority adjustment in the priority scheduling module specifically involves reducing the scheduling priority of medium-priority and low-priority tasks based on the operating indicators of the monitoring and statistics module, when the external API platform's rate limiting is increased or the call success rate decreases, and allocating resources to high-priority real-time transaction and inventory synchronization tasks. When a task triggers an unrecoverable exception, the corresponding task priority is reduced to the lowest level and retry scheduling is prohibited; when a task has the risk of data expiration, the corresponding task priority is temporarily increased.

3. The intelligent retry and traffic coordination control system for commercial APIs according to claim 1, characterized in that, The exception handlers include the Amazon SP-API exception handler and the Amazon Ads API exception handler, which are used to parse the unique exception information of the corresponding platform and determine the recoverability of the exception by combining the error code and the response body content. The retry calculation module configures different exponential backoff coefficients for three types of recoverable exceptions: rate limit, network, and server internal. It also supports adding random jitter values ​​and setting the maximum backoff time threshold.

4. The intelligent retry and traffic coordination control system for commercial APIs according to claim 1, characterized in that, The priority scheduling module uses CompletableFuture to implement asynchronous non-blocking processing of API calls. The background worker thread pool is a configurable daemon thread pool that supports tens of thousands of concurrent API calls and can avoid thread blocking and resource exhaustion.

5. A method for intelligent retry and traffic coordination control for commercial APIs, used in the system described in any one of claims 1 to 4, characterized in that, Includes the following steps: S100. Receive an API call request, the request including an API type identifier, a priority identifier, and business logic, the priority identifier corresponding to a preset basic priority level; S200. Based on the API type identifier, obtain the corresponding adaptive rate limiter from the pre-configured rate limit mapping table, wherein the rate limit mapping table is an independent rate limit strategy for each API endpoint that matches its official quota. S300. Encapsulate the API call request into a priority task and place it in a priority blocking queue; S400: The background worker thread retrieves priority tasks from the priority blocking queue according to priority order; S500: Obtain API call permission through the adaptive rate limiter; S600: Execute API calls and monitor call results and exception information; S700. Update the success rate statistics of the adaptive rate limiter according to the call result, and dynamically adjust the API call rate based on the statistics, and the adjusted rate does not exceed the official rate limit range of the corresponding API endpoint. S800. When an API call fails, the platform-specific exception system is used to identify the exception type and error code to determine whether the exception is a recoverable exception. S900. If the exception is determined to be unrecoverable, return the exception information of the call failure directly; if the exception is determined to be recoverable, calculate the intelligent backoff time based on the number of retries and the exception type. The intelligent backoff time is calculated using a combination of differential coefficient and random jitter. S1000: Put the priority task back into the priority blocking queue and wait for the next scheduling execution.

6. The intelligent retry and traffic coordination control method for commercial APIs according to claim 5, characterized in that, The step S700, which involves dynamically adjusting the API call rate based on statistical data, specifically involves: When the number of consecutive successful calls reaches the first threshold, the current call rate will be increased by a first percentage, and the adjusted rate will not exceed the official maximum rate limit for the corresponding API type. When the number of consecutive failures reaches the second threshold, the current call rate will be reduced by a second percentage, and the adjusted rate will not be lower than the official minimum rate limit for the corresponding API type. When the number of consecutive failures reaches the third threshold, the current call rate will be aggressively reduced by a third percentage, which is greater than the second percentage, and the adjusted rate will not be lower than the official minimum rate limit for the corresponding API type.

7. The intelligent retry and traffic coordination control method for commercial APIs according to claim 5, characterized in that, The differentiated calculation method for the intelligent backoff time in step S900 is as follows: For rate limiting errors, exponential backoff calculation is performed using the first backoff coefficient; For network errors, an exponential backoff calculation is performed using a second backoff coefficient. For internal server errors, an exponential backoff calculation is performed using a third backoff coefficient. Wherein, the first retreat coefficient > the second retreat coefficient > the third retreat coefficient; The random jitter is a random value ranging from 0 to half of the calculated result, added to the result of the exponential backoff calculation, and the final backoff time does not exceed the preset maximum backoff time threshold.

8. The intelligent retry and traffic coordination control method for commercial APIs according to claim 5, characterized in that, Step S800, which involves identifying the exception type and error code based on the platform's unique exception system, specifically includes: If the exception is specific to Amazon SP-API, determine whether it is a recoverable exception based on the returned error code and response body content. If the exception is specific to the Amazon Ads API, determine whether it is a recoverable exception based on the retry flag built into the exception. If the anomaly is a general network anomaly, it is directly determined as a recoverable anomaly; The recoverable anomalies include rate limiting errors, server-side internal errors, and general network anomalies, while unrecoverable anomalies are platform-specific business logic errors.

9. The intelligent retry and traffic coordination control method for commercial APIs according to claim 5, characterized in that, The preset basic priority levels include high priority, medium priority, and low priority, specifically divided as follows: The high-priority tasks are API call tasks related to real-time transactions or inventory synchronization. The priority level is for API call tasks related to order processing or report generation; The low priority tasks are historical data archiving or statistical calculation API call tasks. The priority tasks implement a comparable interface, which sorts them by the numerical value of the priority level, with smaller values ​​indicating higher priority.

10. The method according to claim 9, characterized in that, The method also includes a dynamic floating priority adjustment step: during the API call process, the API call success rate, the external API platform rate limiting status, the timeliness of task data and the type of exception are monitored in real time, and the basic priority of the priority task is dynamically increased or decreased according to the monitoring results, and the background worker thread schedules the task according to the dynamically adjusted real-time priority. The specific rules for adjusting the dynamic floating priority are as follows: When it is detected that the external API platform is increasing its rate limiting or the overall call success rate is decreasing, the scheduling priority of medium and low priority tasks will be automatically reduced, the execution of low priority tasks will be suspended or postponed, and API quotas and system scheduling resources will be allocated to high priority tasks first. When an unrecoverable exception is detected that a priority task triggers a platform-specific business logic error, the priority of the corresponding priority task is directly reduced to the lowest level, and retrying and scheduling of it are prohibited, releasing the occupied API quota and system resources. When it is detected that a certain priority task is not scheduled in time, resulting in insufficient data timeliness or risk of expiration, the priority of the task will be temporarily increased to ensure that the API call is completed within the data validity time window.

Images