感谢您愿意花时间提出这么好的建议。其实的确如您所说，如果是出于成本控制，那么每个月 90 万次请求和 每天 3 万次请求其实差不太多。我们最终选择每天限制 3 万次请求，从执行角度讲是因为 LeanCloud 的计费周期是每天计费，但更重要的是对用户来讲，如果有了使用上限，那么从安全角度讲，上限的粒度是越小越好的。
因为在限制每日用量的情况下，如果应用使用超量，那么最长停用时间也就是一天，造成的损失也比较小。但如果限制的是每月的用量，那么就会出现一个月剩下的时间都要停服的状况。
应用使用超量有两种情况，一是被人攻击，另外一种情况则更常见，就是开发者自己出现了失误，比如写出了死循环，或者某个网络请求会造成大量数据库请求。90 万次的限制看起来虽然多，其实一个死循环跑一会儿也就用完了。
举个例子，云引擎连接数据库是没有网络延迟的，所以可以达到理论上的最快速度。那么如果在云引擎上写一个死循环去请求数据库，假设这个请求服务器处理起来需要 15 毫秒，那么每个工作线程每秒就可以处理 1,000 / 15 = 66.67 个请求。开发版有三个工作线程，那么合起来的 QPS 就是 200。我们算一下，900,000 / 200 / 60 / 60 = 1.25，90 万个请求只要 1 小时 15 分钟就跑完了。
出现这种情况之后，如果限制是每天，那么只要用当天剩下的时间去排查问题，第二天也就可以恢复了；如果限制是当月，那么就会面临很长的服务不可用时间。
我们此前走访了很多家用户，客观来说主要做客户端的开发者往往不是特别熟悉后端的逻辑，所以在开发阶段，由于代码问题导致使用超量的情况，是有挺大几率发生的。我们曾经发现某位用户账单异常地高（与应用规模不成比例），联系并检查后发现是一个云引擎上的定时任务写得有问题。在以前没有限制的情况下，代码出了问题只要多付钱就好了；但在有使用上限的情况下，这很可能会导致整个服务不可用。
