电子邮件API服务供应商Mailgun开源了Gubernator，这是一个原生云计算分布式速率限制微服务，官方提到，微服务架构可以在不影响服务独立性的情况下，提供通用速率限制服务。
当客户端或服务，向Gubernator发出速率限制请求的时候，请求会被赋给键值，并应用散列算法，决定出速率限制请求的拥有节点（Owner）。官方提到，选择单一节点来处理速率限制较为快速，且能避免分布式计数带来的复杂性以及延迟。
而客户端的每个请求都会带有速率限制配置，速率限制的配置便会与现阶段速率限制状态，一起被存在速率限制拥有节点的本地内存中，这些配置具有时效性，当时限到期且没有再次收到速率限制配置，配置便会从缓存中被删除。
Gubernator的架构被设计成，适合在同侪分布式集群中运行，其利用内存缓存所有当前阶段激活的速率限制，Gubernator无状态，没有数据会被同步至磁盘中，官方提到，多数网络速度限制持续的时间只有数秒中，因此当重新启动或是计划性停机，而使得内存内数据丢失，并不是大问题，对于Gubernator来说，也仅是几秒钟的时间，一小部分的流量可能发生过度请求的状况。
Gubernator可以均匀的分散速率限制请求到整个集群，也就是说，用户只要为集群增加一个节点，就能简单地扩展系统，Gubernator不依赖Memcache或是Redis等外部缓存，也不会在磁盘上存储状态，其配置来自客户端传递请求，并且能支持极高吞吐量的应用。
之所以不使用Redis的原因，官方解释，Redis用在速率限制的最佳解决方案，是在Redis上存储一个速率限制脚本，每次速率限制请求都调用该脚本，大部分的工作都会由Redis完成，速率限制微服务只是作为访问Redis的代理。而以Redis实例速率限制功能，将会产生额外的流量，因为每次单一请求，都会产生至少一次往返Redis的访问，而速率限制微服务也需要至少访问Redis一次，因此会在服务中增加至少两次的访问往返。
Gubernator能够处理高吞吐量的请求，官方提到，在正式生产环境中，他们为请求API服务设下两个速率限制条件，一个是HTTP请求速率，另一个则是用于评估用户在特定时间内，用户发送电子邮件的收件人数量，单个Gubernator节点每秒可以处理超过2,000次请求，大多数都在1毫秒内回应。
Mailgun也提到，当用户使用Go语言，也能把Gubernator当作函数库使用，并在顶层使用自有特定模型的速率限制服务，这样不仅能使用Gubernator的功能，还可以将商业逻辑分开，并集成专门领域问题到速率限制服务中。