@Zaxos Dogganos
A general tip, since you are really bound to aggravate the whole Fail2Ban issue by putting it into memory: simply disable the option for persistent IP bans by Fail2Ban.
At this moment, you are using a solution that is actually not a solution.
Read the following remarks, if you will.
A - Fail2Ban and challenges of memory usage
Your memory will be used to the same extent or degree as your disk has been used or overused, with one problem though: any memory failure will shut down the whole system.
Consider your system being under some kind of distributed attack, with a lot of IPs causing traffic to your server: your server will store them (more or less) in memory and, in the long run and/or under heavy loads, your memory is exhausted.
In cases of heavy attacks, the irony is that with the option ":memory:" Fail2Ban is the first program to shut down and/or fail, i.e. it really becomes (literally) Fail 2 Ban (any) IP.
B - Memory usage and common VPS
Most memory of VPS is actually some kind of swap: regular swap, or some kind of advanced sharing of memory on the host system.
In general, providers do not tell you that swap is a large part of memory: you think you have (for instance) 12GB, but this is often 8GB (shared!) memory and 4 GB swap.
If the system is heavily depending on swap, loading into "memory" in cases of attacks and/or heavy attacks will result in using the (very slow) swap, which is a sort of designated disk.
Moreover, in many cases of attacks, any form of heavy usage of shared memory on a VPS will often result in the host system cutting down on memory for the VPS or a problem in the host system itself, leaving the VPS with actual problems.
In short, any assignment of IP bans to memory will lead to problems and/or even the usage of swap, which is not "common memory" (making the ":memory:" option obsolete).
Note that there are many attack scripts, specifically designed to attack vulnerable VPSes in order to disable the host system and primarily the security measures on the host system.
C - Fail2Ban design and persistent IP bans
Fail2Ban uses the SQLite database to create "persistent" IP bans, i.e. bans that are persistent across reboots.
The ":memory:" option does not really create persistent IP bans: every reboot, memory is flushed.
As such, any usage of memory for IP banning is somewhat "strange", at least not adviceable.
D - Fail2Ban performance and factual quality
Fail2Ban has been started as an admirable project and it still is, but with the introduction of the "persistent" IP bans, all other bugs and bug fixes were more or less forgotten.
This has been a trend that also applies to the SQLite database approach for persistency: it is not the best approach, for many reasons (and patches are not coming shortly).
Moreover, even given a specific level of quality of the code behind Fail2Ban, Fail2Ban performs AND behaves poorly when using the ":memory:" option.
In short, it is one of the many options associated with Fail2Ban, that should not be used.
A number of similar remarks can be made with respect to other Fail2Ban options, such as the option to "connect" with one or more blacklists: it is possible, but not preferable.
E - Conclusion
Everybody can do a lot with Fail2Ban, but the most intricate solutions are not the domain of Fail2Ban: it is a crude solution, a "second line of defense" solution.
After all, malicious traffic should simply not enter the system and cause lines in the various log files scanned by Fail2Ban.
In conclusion, the emphasis should be more on a proper firewall setup, only followed by a proper setup of the second line of defense offered by Fail2Ban.
And yes, Fail2Ban enters iptables rule sets, but only does so after entry has been granted by a lack of other firewall rules.
One should simply be one step ahead: block malicious IPs BEFORE any entry (i.e. traffic) has been allowed.
Regards....