Plan for ensuring smooth communication between overseas systems and domestic systems via API

Due to overseas business needs, the server is deployed in Singapore. However, the services that synchronize with each other are deployed in China.
The production environment often encounters the overseas API synchronization business interface to the domestic use of the package (this kind of problem rarely occurs when the domestic overseas API is adjusted!)
In order to solve this problem, two solutions have been tried:
Solution 1:
On the overseas server, link and call the domestic redis -sidekiq writes the task, responds to the task on the domestic server and then links to the overseas database to fetch the data and write it to the domestic server.
This seems to have a good effect. However, overseas transfer of domestic task queues, and domestic logic links are written to process overseas databases. Too much coupling to each other.

Option 2:
When calling overseas APIs, add status table records, interface names and parameters, and feedback status.
If the call status returns successfully, the call will not be repeated, otherwise the call will be polled in 5 minutes.
With the redis-sidekiq overseas task queue basically repeating the call 3 times can also solve the problem.
It should be noted that, in the domestic interface, some logical judgments of unique creation and synchronization should be made, and repeated calls may enter repeated data. The benefit is decoupling.