anchor.diff:  === Generic production checklist
  -The considerations described bellow are applicable to each solution based on the token-bucket or leaky-bucket algorithm.
  -You need to understand, agree and configure following points:
  +The considerations described below apply to each solution based on the token-bucket or leaky-bucket algorithm.
  +You need to understand, agree, and configure the following points:
   
   ==== Be wary of long periods
   When you are planning to use any solution based on token-bucket for throttling incoming requests,
  
positive.code: 
  [[short-timed-bursts, short-timed bursts]]
  ==== Be wary of short-timed bursts
  Token bucket is an efficient algorithm with low and fixed memory footprint, independently of the incoming request-rate(it can be millions per second) the bucket consumes no more then 40 bytes(five longs).
  But an efficient memory footprint has its own cost - bandwidth limitation is only satisfied over a long period of time. In other words you cannot avoid short-timed bursts.
  
  .Let us describe an example of local burst:
  * Given a bucket with a limit of 100 tokens/min. We start with a full bucket, i.e. with 100 tokens.
  * At ``T1`` 100 requests are made and thus the bucket becomes empty.
  * At ``T1+1min`` the bucket is full again because tokens fully regenerated and we can immediately consume 100 tokens.
  * This means that between  ``T1`` and ``T1+1min`` we have consumed 200 tokens. Over a long period of time there will be no more than 100 requests per min, but as shown above it is possible to burst at **twice the limit** here at 100 tokens per min.
  
  .These bursts are inherent to token bucket algorithms and cannot be avoided. If short-timed bursts are unacceptable you then have three options:
  * Do not use Bucket4j or any other solution implemented on top of token-bucket algorithms, because token-bucket is specially designed for network traffic management devices for which short-living traffic spike is a regular case, trying to avoid spike at all contradicts with the nature of token-bucket.
  * Since the value of burst always equals to capacity, try to reduce the capacity and speed of refill. For example if you have ***strong*** requirements ``100tokens/60seconds`` then configure bucket as ``capacity=50tokens  refill=50tokens/60seconds``. It worth to mention that this way leads to following drawbacks:
  -- In one time you are not allowed to consume amount of tokens greater than capacity, according to example above - before capacity reducing you was able to consume 100 tokens in single request, after reducing you are able to consume 50 tokens in one request at max.
  -- Reducing the speed of refill leads to underconsumptions on long term periods, it is obvious that with refill ``50tokens/60seconds`` you will be able to consume 3050 tokens for 1 hour, instead of 6100(as was prior refill reducing).
  -- As a summary of two drawbacks above, we can say that you will pay via **underconsumption** for eliminating the risk of **overconsumption**.
negative.code: 
  .Example of a dangerous configuration:
  * Given a bucket with a limit of 10000 tokens/ per 1 hour per user.
  * A malicious attacker may send 9999 requests in a very short period, for example within 10 seconds. This would correspond to 100 requests per second which could seriously impact your system.
  * A skilled attacker could stop at 9999 requests per hour, and repeat every hour, which would make this attack impossible to detect (because the limit would not be reached).
  
  To protect from this kind of attack, you should specify multiple limits like bellow
  [source, java]
  ----
  Bucket bucket = Bucket.builder()
  