You are correct about backpressure being handled automatically because of pull model instead of the push model by RabbitMQ. But you are incorrect regarding the leader election. We dont push directly to RMQ. We enqueue first to HBase and only the eligible messages are pushed to RMQ. We still would need leader election while consuming from HBase. Any messaging queue could have been used when eligible messages are found from HBase. Kafka is ops heavy. It requires a lot of operational overhead. RMQ is very light on operations. If your organization already has a Kafka cluster then it can be used.

If we were to run it as a single job only, would we eliminate the need for the leader election component? Yes, but we would limit our throughput (the number of records fetched by an HBase scan in a given period) - If we run multiple concurrent Hbase scans, each without any overlap, then we will be able to scale our scans horizontally and serve the ever increasing traffic :)