Rate Limiter 

Here is a more sophisticated discussion. 

1. General Goal
   1. Limit the number of actions within a period of time
   2. Open Source: Ruby / Django. Memcached.
2. Scenario
   1. Feature: IP / User / Email
      1. Limite Login: IP & Email
      2. Buy Ticket: IP & User
   2. Criteria:
      1. Time period (minutes, hours, days)
3. Storage
   1. Requirement
      1. Need to log feature (IP/User/Email)/ time / event (Login/Buy Ticket, etc). The number of times.
      2. No need to keep history above the range.
      3. Need high efficient read/write access. (In-memory).
      4. No need to store the data permanently. (In-memory).
   2. Design
      1. Use feature + timestamp + event as key
      2. Use Memcached increment to record access. (Access + 1. TTL = 60s.)
      3. Use a ring buffer fashion.
      4. Accumulate the sum of access within the period.
   3. Trade-Off – Bucket
      1. When using the day as a limitation period, use the hour bucket.
      2. When using the hour as a limitation period, use the minute bucket.
      3. Etc.

DataDog

1. Scenario
   1. Record access to a specific link within a period of time. Form a curve
2. Storage
   1. Most write. Less read.
   2. Need persistent storage. (cannot in-memory)
   3. SQL / NoSQL / FS: All acceptable. Take NoSQL as an example.
   4. Store the historical data in the unit of times.
      1. Today, data points per minute.
      2. Lastday, data points per 5 minutes.
      3. Last month, data points per hour.
      4. Etc.
   5. Optimization:
      1. Aggregation: Reduce QPS
         1. Buffer the information at the webserver locally. Sync the information to the Datadog server periodically. (For example, per 15 seconds)
            1. Reduce QPS.
            2. Overload depends on the number of web servers. Not the number of users.
      2. Retention: Reduce data size
         1. Change the data statistics to coarse granularity.