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