Could you consider "Delay after queue" node?

Yes. But main issue is “in queue”. As I talk, I could build a seperated data to solve this.
If you try to build a function to solve problem in queue, you must try to solve in a random number of request, like 30 or 300 requests…

A node for “queue” will try to build a automatic function to make a queue. This could find way to make order for requests in queue. I do not need to pay attention to data of requests, or how many requests I have.

You could know about this logic in explaination zapier link above. They know “in queue” is another kind of delay which is helpful in this case. You must do every request, but force them to do one-by-one, and in order first-to-last, not the same time.

This solve issues when other database through API have not updated yet, but need to get different IDs for tasks.

This look like:

Workflow without queue
[request 1] - [workflow]<at 9:00 am> - Got task id 01 <done at 9:00>
[request 2] - [workflow]<at 9:00 am> - Got task id 01 <Error! Duplicated ID>
[request 3] - [workflow]<at 9:05 am> - Got task id 02 <done at 9:05>

Workflow with queue
[request 1] - [workflow have queue node]<at 9:00 am> - [queue 1] - Got task id 01 <done at 9:00>
[request 2] - [workflow have queue node]<at 9:00 am> - [queue 2] - Got task id 02 <done at 9:01>
[request 3] - [workflow have queue node]<at 9:05 am> - [queue 1] - Got task id 03 <done at 9:05>