POC Event bus notifications using Postgres Notify/Listen

[quantranhong1999]

Why

Experiment the possibility of replacing RabbitMQ with Postgres Notify/Listen, starting simply with the Event bus notifications part first (should be more straightforward than the work/mail queues ones).

Do a POC like the Redis event bus notifications to see how it goes. If the result is good, we may proceed further with the mail queue implementation.

How

• Implement in tmail-backend only the EventBus notifications part. (we can have a look at https://github.com/linagora/tmail-backend/pull/943)
• Make the contract tests green at best
• Compose a runnable TMail docker image and perform a performance test to see if it is stable and fast enough.

DoD

Conclusion if we move on further the Postgres Notify/Listen topic.

[quantranhong1999]

I put the POC in the tmail-backend scope (instead of the james-project) to help us ease testing the POC (rather than do a part on James and then a part on TMail)

[chibenwa]

Hi, WHile we can work on this, let's make the development effort minimal. Few mandays max. To be fair the logic behing that is to package a simple to use James server we could easily ship into debian. But to that end a non scalable james server likely does the job... To conclude the need needs to be refined :-p

[quantranhong1999]

https://github.com/linagora/tmail-backend/pull/1104

[Arsnael]

Decided that it was not worth it to go any further in this topic. The perf is still better with fully rabbitmq and it does not make sense to use postgres if we don't move all queues to it.