Hello team, I have one problem to solve, all ideas are welcome. Problem: How t . . .

Mayur Sharma:
Hello team,

I have one problem to solve, all ideas are welcome.

Problem: How to send broadcast message (http or socket) to all the pod replicas?

Scenario: Module A has 2 replica of pod, client can go on any of the pod to get the data via service. and client is polling at every 20s to get the data.
Now, another module B (of replicas 2) has prepared the data and want to send the data to module A, so that pod of module A can send data back to client on one of his poll request.
Here, as service can redirect request to any one of the pod, pod of module B can send the data to only one of the pod of module A. So, I fear the poll request from client may go to wrong pod of A and may hang it there!

I want to send data to all of the pods of module A, and cannot implement any new technology as it would increase the scope. Is there any construct in K8s that we can send data to all the pod replicas?

Mumshad Mannambeth:
The design of the application, in this case, is not cloud native and not suitable to be hosted on containers/kubernetes. Cloud native applications must adhere to the 12 factor app methodology. As per the twelve-factor app:

Twelve-factor processes are stateless and http://en.wikipedia.org/wiki/Shared_nothing_architecture|share-nothing. Any data that needs to persist must be stored in a stateful <https://12factor.net/backing-services|backing service>, typically a database.

Read more about it here:
https://12factor.net/processes

So as per this, your module B should never rely on a particular pod on module A. Instead it should be able to send request to any pod on module A and any pod on module A should be able to serve that request.

You can still implement broadcast messages using a caching service like redis. Attach all pods in module A to another service like redis and listen to broadcast messages.

Mayur Sharma:
@Mumshad Mannambeth: Thanks for sharing the insights.

"Instead it should be able to send request to any pod on module A and any pod on module A should be able to serve that request."

Yes, that’s exactly I want. Seems, a middle service (like cache or topics) for storing data needs to be implemented.

R Banerjee:
Suggestion, you can also use a messaging queue , and send the prepared data to the queue ( rabbitmq, for example ) and then let Module A handle it. Module A can send the data back on another queue which B can listen to. That ways you can maintain a stateless configuration ( just a thought , but yes, similar to cache maybe)

A Real Life example is the Openstack service in cloud.