<p>I'm studying how to make a chat service with gRPC. I notice that most of the examples store all the subscriber's connections into a List data structure. When the chatroom got a new message, the server will loop through that List and send new messages.</p>
<p>Stores subscribers in <a href="https://github.com/Raaaaaaaay86/grpc-chat-server/blob/master/src/main/java/com/example/grpcchatserver/observer/ChannelObserver.java" rel="nofollow noreferrer">source code's</a> variable <strong>subscribers</strong>.</p>
<p>My question is that when the subscriber number grows up and storing all the subscribers in the HashMap seems like a bad idea because that will cost too much memory? I have tried to store those connections in Redis but it might be impossible <a href="https://stackoverflow.com/questions/57848633/how-to-make-grpc-streamobserver-object-serializable-in-java">due to the connection is not serializable.</a></p>
<p>My Idea is when I deploy multiple pod instances in Kubernetes. Each chat service becomes independent. How could I get the subscribers correctly when they are distributed on different servers?</p>

<p>Here are a couple of aspects that I'm thinking:</p>
<ul>
<li>Any chat system has some limits in terms of chatroom size. How many subscribers do you want to support? If you want to support tens (or even hundreds) of subscribers, I believe it works well with an in-memory list of subscribers, since it's much faster than having the subscriber's list in an external cache</li>
</ul>
<ul>
<li>When you need to send a message to the entire list of subscribers, instead of looping on that list, you can do that in parallel, using an IO-optimized thread-pool.</li>
<li>Deploying your chat-service in a pod is a good idea, you need the ability to scale horizontally, but you also need a smart-gateway in front of your service, to route the requests from a given user, to the pod that stores its information (if the subscribers list is stored in memory). Otherwise, if this info is stored externally (in a cache), your chat service can be fully stateless.</li>
</ul>
