Why implement “Quota as a Service”? • We are developing / managing Monitoring system • Very many requests • Easy to abuse → We need Quota/Rate Limit for our services
Don’t use Quota / RateLimit lib simply? • LINE has many services (also our team) • Need Quota / RateLimit per services • Need manage configurations for each services • Need database for each services • Not want to manage extra DBs…
Token Bucket Algorithm 1. Add Tokens into Bucket per 1/r seconds • Bucket can hold b Tokens 2. When n bytes packet is coming, remove n Tokens and send the packet 3. If Bucket does not have n Tokens, the packet becomes non-conformant • Drop the packet • Queue the packet until Bucket charges enough Tokens • Send with non-conformant flag
Leaky Bucket Algorithm • A fixed capacity bucket • If the bucket is empty, stops leaking • Packet is water • It is possible to add a specific amount of packet to the bucket • If the amount of packet would cause the bucket to exceed its capacity, then the packet is non-conformant
Generate Codes as possible as we can • gRPC + REST • gRPC: rate limiting • REST: registration • gRPC server/client code generated from Protocol Buffers • REST server/client code generated from OpenAPI spec • Mock from interfaces
Central Dogma • Service Configuration Repository by LINE • Highly available • Version Controlled based on Git • Can watch by client • Apply config change by event base • Can mirror GitHub to Central Dogma
Reduce Services We Should Manage • Configuration Management • GitHub Pull Request for WUI + Central Dogma as Database • User Authentication / User metadata DB • LDAP + session store (Redis)