基于在组中所有服务器上收集的指标，节流机制启动并决定是否限制成员能够执行/提交新事务的速率。

因此，从所有成员获取的指标是计算每个成员容量的基础：如果一个成员有一个大队列（用于认证或应用程序线程），那么执行新事务的能力应该接近于认证或应用的容量最后一期。

组中所有成员的最低容量决定了组的实际容量，而本地事务的数量决定了有多少成员正在写入它，因此，可用容量应该与多少成员共享。

这意味着每个成员都有一个基于可用容量的既定写入配额，换句话说，它可以在下一个时期安全地发布一些事务。如果验证者或二进制日志应用程序的队列大小超过用户定义的阈值，则限制机制会强制执行 writer-quota。

配额减少了上一周期延迟的事务数，然后还进一步减少了 10%，以允许触发问题的队列减小其大小。一旦队列大小超过阈值，为了避免吞吐量大幅跃升，在此之后的每个周期，吞吐量只允许增长相同的 10%。

当前的节流机制不会对低于配额的交易进行处罚，而是延迟完成那些超过配额的交易，直到监控期结束。因此，如果发出的写入请求的配额非常小，则某些事务的延迟可能接近监控周期。