suppose that the order is confirmed and then pushed to the remote server, and the API limits it to 70 times per minute. It thinks of the following solutions:

1. Each click will request an API, wait for the result to return and verify the result. Problem: the frequency limit may be exceeded, it is difficult to verify whether all requests are successful, and the waiting time of the request API is long. The batch request failed and cannot be retried.

2. Add a request success flag to each order, and bury points for user operations, such as when a user queries an order, each time the user operation arrives here, it is triggered to check whether the last request was successful and whether there was a successful continuation request. The advantage is that if the request fails, you can try again. But if the user does not act, he may never ask again. And the frequency is not easy to control. If there are too many unsuccessful requests for some reason, the waiting time for too many users in one request will be inexplicably longer

3. Use a server and Redis as an asynchronous service queue, and push the requested parameters directly to the request queue each time you need the API, and then specially handle it by the server. The advantage is that it is easy to limit the frequency, and if the request fails, you can try again, and the waiting time for the user"s foreground experience is reduced due to asynchronous operation.

if it is a query, such as querying the order, it is relatively simple to cache the data in redis, to set the expiration time. So you don"t have to query every time.