It's real-time by default. Done in a cheap (and efficient) way. The views update automatically when relevant data changes, no possibility of overriding conflicts when editing concurrently. Changes are only distributed to users/clients who are looking at the affected data.
It's not just for chat. Anytime people update data collaboratively, for any data-driven software, you run into issues of people overwriting each other's changes... Sadly users got really used to poor experiences like having to 'refresh the page', or 'locking down resources' during edits to avoid concurrent editing altogether.
It's been kind of disturbing for me to realize how few people care about data integrity in collaborative scenarios. It's a kind of hidden issue which can cause major problems but users tend to tolerate. I've had this experience first-hand with colleagues using various other platforms where someone else had the same resource open for a while in the browser, we updated different fields and my field was overwritten with its old value but we didn't realise for some time until it caused a bug with one of the workflows. Then it was like "I'm sure I updated that value."
SC's pub/sub channels are part of the secret sauce to make this work. SocketCluster makes some unique tradeoffs with its pub/sub mechanism; the channels are extremely cheap to create and are cleaned up automatically (and cheaply)... And at any scale with sharding. This was an intentional design decision which is different from message queues like Kafka and RabbitMQ which prioritise throughput and are typically used in the backend as opposed to being end-to-end.
