[ADR] 53. Email rate limiting

[vttranlina]

No description provided.

[chibenwa]

Please use number 52 not to have conflicts with the Pulsar PR...

[chibenwa]

Looks good to me.

Thanks for proposing this.

[Arsnael]

Just typo remarks, but good job overall :)

[mbaechler]

Isn't Cassandra good enough? or you really want non-persistent data storage to have better performance? What about using Pulsar or Rabbit to propagate counters and use an in-memory datastructure on each node?

[vttranlina]

You really want non-persistent data storage to have better performance?

Yes,
More point, with Redis

• we don't need to revoke expired data manually. All counters will be removed after the end of the period (easy to reset counter to zero).
• Redis support atomic API "getAndIncrement" counters

What about using Pulsar or Rabbit to propagate counters and use an in-memory datastructure on each node?

I don't sure about Pulsar (I don't use it before).
But with RabbitMQ, IMO, It does not guarantee the order of messages -> inconsistency counter

[vttranlina]

• Using a message queue will increase the delay of counter more than using a central database

[chibenwa]

Isn't Cassandra good enough?

Cassandra counters are terrible. Actually I want to try alternatives.

or you really want non-persistent data storage to have better performance?

Yes here the tradeoffs of loosing state IMO is outwaited by better performance.

What about using Pulsar or Rabbit to propagate counters and use an in-memory datastructure on each node?

Others are free not to use it and come up with imaginative solutions to implement this.

@vttranlina that's nonetheless interesting remarks, we could have an alternative section explaining that 1. we do not use Cassandra and its counters for performance reasons nor a Cassandra time serie (because it seems complex) and want to avoid the hammer-nail syndrom.

We can then explain that streaming based systems could be used - but might have implications in term of scalability and implementation complexity. Of course our choice should not be exclusive of alternative solutions. We can show that by splitting the rate limiting maven plugin in two: one for the RateLimiter API and the mailet tooling, one for the Redis implementation....

Would this sound fair to you @mbaechler ?

[mbaechler]

Yes. Anyway, I was just curious about the Redis choice, I have a very bad experience performance-wise with Redis.
Cassandra is probably not better for that.
And I think that an in-memory solution fits the need for the reason you described, too.

[chibenwa]

I was just curious about the Redis choice

So do I.

Honnestly if we get a bad experience too we will try data-grids out ;-)

[quantranhong1999]

I read the Guava Rate limiter docs and I do not think its API support rate-limiting by other time units than Second directly. Should we consider other libraries?
I found this library: https://github.com/mokies/ratelimitj
It provides 2 implementations: Inmemory and Redis. The interesting thing is its Redis implementation uses lettuce-io reactive Redis client. So IMO we could benefit it reducing some Redis client code and counters implementation also.

[chibenwa]

Hi Quan!

This is a very good comment!

I read the Guava Rate limiter docs and I do not think its API support rate-limiting by other time units than Second directly.

Yes this could be problematic as saying "I allow you 100 mails per hour" is not the same as "I allow you one mail every 36 seconds". Also the Guava rate limiter is blocking which is not really fancy.

Should we consider other libraries?

We should ALWAYS look for alternatives!

It provides 2 implementations: Inmemory and Redis. The interesting thing is its Redis implementation uses lettuce-io reactive Redis client. So IMO we could benefit it reducing some Redis client code and counters implementation also.

This is of course very interesting!

Yet there is one key point to me: We need a James interface in plain Java (or Scala) fully abstracting away the RateLimitJ that would then just be an implementation detail (for memory AND redis implementations).

Also the concept of "batching rules together" is interesting. We should definitly add this concept to our rate limiter API as well

(

RedisRateLimiterFactory factory = new RedisRateLimiterFactory(RedisClient.create("redis://localhost"));
Set<RequestLimitRule> rules = new HashSet<>();
rules.add(RequestLimitRule.of(Duration.ofSeconds(1), 10));
rules.add(RequestLimitRule.of(Duration.ofSeconds(3600), 240).withPrecision(60));
ReactiveRequestRateLimiter requestRateLimiter = factory.getInstanceReactive(rules);
Mono<Boolean> overLimit = requestRateLimiter.overLimitWhenIncrementedReactive("ip:127.0.1.6");

)

@quantranhong1999 can you propose changes to this ADR following your remarks?

[chibenwa]

Also, you propose an external dependency.

Can I ask you to do a quick assessment regarding the health of that community?

-> License ?
-> Are there recent releases ? Are the release frequent ?
-> Code activity ? Release cycles ?
-> Companies behind this ?
-> Are PR and Issues actively / passively managed ?
-> Are there some forums/chats where we can ask questions if we have issues ? Do people receive answers ?
-> Are there several maintainers or is it more or less one guy ?

(Ultimately the question is will we save more energy on the long run depending on this dependency?)

(and yes, we should do this assessment every time we add a dependency)

[quantranhong1999]

License ?

Apache License 2.0

Are there recent releases ? Are the release frequent ?

The latest release is May 2021.

Code activity ? Release cycles ?

The latest code update is 8 months ago and none recently.

It looks like the release cycles is about 6 months to 1 year.

Are PR and Issues actively / passively managed ?

I see some issues without answers recently.

Are there some forums/chats where we can ask questions if we have issues ? Do people receive answers ?

I do not see anything but Github.

Are there several maintainers or is it more or less one guy ?

There are 10 contributors but mostly Craig Baker is the main author.
He is the Chief architect at Afterpay (a quite big fintech in Australia). I think it is his personal project other than being backed by his company.

It has 413 stars so I think it is good enough. IMO it may be good enough for us in near future but it is a risk for the long future because it likely has 1 main contributor.