Restricting input is the simplest way to manage message queue growth in Erlang systems.
It’s the simplest approach because it basically means you’re slowing the user down (applying back-pressure), which instantly fixes the problem without any further optimization required.
On the other hand, it can lead to a really crappy experience for the user.
The most common way to restrict data input is to make calls to a process whose queue would grow in uncontrollable ways synchronously. By requiring a response before moving on to the next request, you will generally ensure that the direct source of the problem will be slowed down.
The difficult part for this approach is that the bottleneck causing the queue to grow is usually not at the edge of the system, but deep inside it, which you find after optimizing nearly everything that came before. Such bottlenecks will often be database operations, disk operations, or some service over the network.
This means that when you introduce synchronous behaviour deep in the system, you’ll possibly need to handle back-pressure, level by level, until you end up at the system’s edges and can tell the user, "please slow down."
这个方法的难度在于造成消息队列增长的短板通常不是系统边缘(the edge of the system)导致的，当你深入理解后，你就会发现要去优化系统的每个细节。这个瓶颈通常来自于数据库操作，硬盘读写，或其它要借住网络的服务。
Developers that see this pattern will often try to put API limits per user 8 on the system entry points. This is a valid approach, especially since it can guarantee a basic quality of service (QoS) to the system and allows one to allocate resources as fairly (or unfairly) as desired.
通常开发者看到这种模式会试图在系统的入口的API针对每个用户都做限制8。 这的确是一个有效的方法，特别是可以保证一个最基本的服务质量(base quality of service,QoS)。可以允许用户公平（或不公平）地分配资源。
 There’s a tradeoff between slowing down all requests equally or using rate-limiting, both of which are valid. Rate-limiting per user would mean you’d still need to increase capacity or lower the limits of all users when more new users hammer your system, whereas a synchronous system that indiscriminately blocks
should adapt to any load with more ease, but possibly unfairly.