Consider applying inMemoryBlockOnConsumed to RateLimiter.get(key) as well as consume().
The example given for login protection at https://github.com/animir/node-rate-limiter-flexible/wiki/Overall-example#login-endpoint-protection does seem to require using the get(key) calls at the start, as it should probably not consume on the limiters until the the login attempt has failed (and users existence has been verified for user/ip combo).

However this means that using inMemoryBlockOnConsumed does not actually help reduce database traffic due to the need for the RateLimiter.get(key) call, which doesn't check the in memory version like consume does.
=>
What is worse, it causes the consumedPoints checks that depend on the get(key) call at the start (prior to trying to login the user) to never trigger properly (unless inMemoryBlockOnConsumed is larger than points) because it blocks on consume in memory only and never writes the failing point deduction to the database; but the database is what is being checked with the get(key) call that can then therefore never fail.

Maybe there is a way to refactor this example to make use of the inMemoryBlockOnConsumed optimization/protection, but at present I don't see a nice way to do that.  Additionally since even trying to use the inMemoryBlockOnConsumed with the example seems to break the use case, it seems that the get(key) should probably use inMemoryBlockOnConsumed in addition to consume.

I assume that there is a reason inMemoryBlockOnConsumed is presently ONLY used in consume(), but it seems like if there was another place that it makes sense to use/check it, it would be for local read only (ie the get(key) call).