我正在考虑实现一个顶级通用后端，使用非阻塞请求（使用 Promise、Futures 等）通过 HTTP 调用各种专用后端。
对其他后端的调用/请求的响应可能需要几秒钟甚至几分钟。
我知道每个非阻塞请求都应该将诸如承诺或未来之类的东西放入我的顶级通用（非专业）后端的承诺/未来队列中。
当顶级后端发出请求时，promise/futures 队列就会增长。
当队列中的请求得到响应并使用相应的 Promise/Future 时，队列会变得更短。
我无法得到一件事。
如果我的顶级通用后端每秒发出 1000 个 HTTP 请求，并且某些请求可能需要几秒钟（非常慢）和几分钟（非常慢）才能获得响应，平均而言，我们假设一个请求需要 1 分钟才能获得响应它的响应那么它应该意味着底层语言/技术/框架和硬件/RAM/磁盘/任何应该能够保留/维护/处理 60K 个承诺/期货的队列。
然后，如果速率更高，例如每秒 100K 请求，那么应该有能力维护 6M 个 Promise/Futures 的队列。
我内心的某种感觉告诉我，在我的顶级后端运行时的每个时刻都有 6M 未完成的 Promise/Futures 是错误的、不可靠的，并且不太可能得到各种后端技术（如非阻塞 Java 框架/Node.js/其他非阻塞）的支持。 -各种编程语言的阻塞框架。
我可以考虑扩展顶级后端（到多个较小的统一实例），以将其承诺/未来队列保持在所选技术/硬件的能力范围内。
然而我有一种感觉，长期请求/承诺/未来的做法是错误的，应该还有其他我不记得或不知道的东西。
我觉得让专门的后端立即响应“确认，工作”并轮询结果可能是一个更好的选择，但它会延迟轮询速率间隔的时间分数更快的响应。
问题不受任何特定语言、框架或技术的约束。然而，如果您觉得您可以使用您选择的任何语言/框架/技术使用某些数字和代码片段来回答，请分享您的答案。
问题是： 让每秒数千个非阻塞 HTTP 请求在几秒和几分钟内得到响应是否可以？ 请分享一个成功运行的示例。
附注我希望这个问题能够得到某些精确的答案并符合 SO 规则。
维护 6M 个 Promise/Future 的队列。
PC电脑一般有64K端口，因此我认为一台PC无法同时维持6M（涉及端口）的承诺。
但在 PC 世界之外，也许有特定的硬件确实具有支持此功能的端口。