在最近的博客文章中，Uber（Uber的限流系统）和OpenAI（超越限流限制：扩展对Codex和Sora的服务访问）都提到了自己在限流策略上所做的调整：从基于计数的、针对具体服务的限流机制，转向了更加灵活的、基于策略的限流系统。这两家公司都开发了自己的专有限流平台，并将这些平台部署在基础设施层。这些新系统采用了软限制机制，通过向客户端施加压力来管理流量，而不是采用硬性切断连接的方式——无论是通过概率性限流机制，还是基于信用额度的限流方案——从而确保系统的稳定性，同时不会影响用户的正常使用体验。
此前，Uber的工程师们是为每个服务单独设置限流的，通常会使用由Redis支持的令牌桶机制来实现这一目标。然而，这种做法导致了运营效率低下，比如会增加延迟，而且还需要频繁调整限流阈值。配置上的不一致性也增加了维护难度，并导致不同服务的保护力度不均衡，有些小型服务甚至完全没有限流限制。此外，由于限流机制的分布较为分散，因此很难准确判断哪些问题是由限流措施引起的。
Uber用新的全球限流系统取代了原有的旧限流机制。该系统的架构包含三个层级：Uber服务网格数据层中的限流组件会在当地执行限流决策，区域聚合器负责收集相关数据，而地区控制器则会计算出全局性的限流阈值，并将这些阈值发送回各个客户端。
GRL系统还用一种新的机制取代了原有的硬性限流机制——它只会拒绝一定比例的请求流量（例如10%）。这种基于策略的限流方式实际上是一种软限制措施，它能够向使用受限的服务施加压力，使这些服务得以继续运行，而不会因为额度耗尽而被关闭。
OpenAI也采用了类似的架构来实施新的限流系统。不过，对于OpenAI来说，推动这一变革的主要因素是提升Codex和Sora应用程序的用户体验，而非确保系统的运营稳定性。随着这些工具被越来越多的人使用，OpenAI发现了一个普遍存在的问题：用户虽然能够从这些工具中获得很多价值，但却经常因为限流机制而受到干扰。尽管这样的限流措施有助于保证公平的使用环境及系统的稳定性，但它们却常常让那些积极使用的用户感到不满。因此，OpenAI试图找到一种方法，在不影响用户使用热情的前提下，继续维持系统的良好运行状态。
OpenAI的工程团队设计了一种综合性的解决方案：用户可以在规定的范围内自由使用系统，超过这个范围后，系统会从用户的信用额度中扣除相应的费用。该团队将这种决策机制称为“瀑布式限流模型”：
这种模型真实反映了用户实际使用产品时的体验。限流措施、免费试用版本、信用额度、促销活动以及企业专属权限，其实都只是这个决策机制中的不同环节而已。从用户的角度来看，他们并没有“切换到另一个系统”，而只是继续使用Codex和Sora而已。因此，信用额度这种机制看起来几乎是“隐形”的——它只不过是瀑布式限流模型中的一个组成部分罢了。