Introduction of Redis based Pub/Sub in the Bazaar Tech Ecosystem

What is Pub/Sub in Redis?

Pub/Sub is a messaging pattern within Redis that facilitates real-time communication between different parts of applications by broadcasting messages to subscribers through channels. This decoupled architecture enables applications to react to events and updates without tight integration, making it valuable for scenarios like real-time notifications, chat applications, and event broadcasting. Redis Pub/Sub’s simplicity and speed enhance application responsiveness, making it a useful tool for asynchronous communication and scalability. This guide explores its core concepts, implementation, and benefits for creating responsive and efficient applications.

Problem Statement

The chat system between the chat app and the agent (using the third-party portal) was running on a single pod. The reason for the single pod was that when the third-party portal needs to reply to a message, it doesn’t have visibility into the specific pod where the connection is established since the reply is coming through a webhook. This lack of information creates difficulties in routing the messages to the appropriate pod where the session with mobile is established, due to which we were running it on a single pod which poses scalability challenges.

third party Response:

 {
  sessionId,
  message
 }

Initial Solution: Kafka

We already use Kafka intensively, so initially we thought of using Kafka for our use case by broadcasting messages which would also align with our current infrastructure and reduce our technical investment.

Limitations with Kafka

By design, Kafka doesn’t allow broadcasting the same messages to both pods simultaneously it always distributes the messages which was not helping in our use case.

Some of the approaches we experimented with Kafka are written below with their issues:

1. Generate consumer ids on runtime for multiple instances of chat service. The idea behind this change was that each individual service instance will have its own unique consumer (due to random consumer id) which will listen for the published messages. The reason we didn’t opt for this change was: Due to any reason if our chat-service pods restart, we would require a manual cleanup of the dynamically created old consumer groups since the consumer-id generation logic was being done at runtime leading to unexpected behavior.
2. Inject consumer-id on runtime using application.yml: This idea was also not possible since both pods were running replicas of the same service.

Our Solution: Redis Pub/Sub

After conducting thorough research, we discovered a viable solution to address the challenges faced by the chat system. By implementing the Redis Pub/Sub mechanism, we effectively handled the message flow between the third-party webhook and multiple pods. With this solution, all the messages received from the third-party webhook are published to both pods simultaneously. When a message arrives, the pod that has the corresponding session consumes and processes it, while simultaneously advancing the offset for both pods. This approach ensures that the messages are efficiently distributed among the pods based on their associated sessions, allowing for parallel processing and eliminating the need for a single pod.

Additionally, to enhance the overall efficiency and user experience, we introduced a sticky socket session mechanism. By implementing this mechanism, we ensured that the connection established from the mobile app to the pods remains consistent throughout the chat session. This allows for seamless communication between the chat app and the agent, ensuring uninterrupted chat exchanges and optimal performance.

By leveraging the power of Redis Pub/Sub and implementing the sticky socket session, we achieved improved scalability, enhanced performance, and a more reliable chat system.

Conclusion

In conclusion, the integration of Redis Pub/Sub within the Bazaar Tech Ecosystem has enhanced the chat system’s architecture, addressing the challenges of single-pod limitations. Redis Pub/Sub’s messaging pattern has brought efficient real-time communication by broadcasting messages to subscribers through channels, eliminating the need for tight integration and enabling dynamic event-driven interactions. This transformation has resulted in improved scalability, responsiveness, and overall performance. The adoption of Redis Pub/Sub, coupled with the implementation of a sticky socket session mechanism, has not only resolved routing issues but also ensured uninterrupted communication between the chat app and the agent, creating a seamless user experience. This enhancement reflects our commitment to innovative solutions and sets the stage for further optimization of real-time communication in future applications.

Disclaimer:

Bazaar Technologies believes in sharing knowledge and freedom of expression, and it encourages it’s colleagues and friends to share knowledge, experiences and opinions in written form on it’s medium publication, in a hope that some people across the globe might find the content helpful. However the content shared in this post and other posts on this medium publication mostly describe and highlight the opinions of the authors, which might or might not be the actual and official perspective of Bazaar Technologies.

Thank you very much for taking your valuable time to read my article. Don’t forget to clap if you liked this article 👏🏻