If a live room depends only on the frontend refreshing APIs on a timer, it hits limits quickly.

Comments need to appear promptly. Online state needs updating. Room state may change. Operations staff want realtime feedback. Polling can work for a while, but once interaction and online statistics become core experience, it stresses the frontend, backend, and database.

Realtime Is Not for Showing Off

I do not add realtime capability just to say the system uses WebSocket. A live room needs realtime because both user experience and operations depend on it.

If comments appear several seconds late, interaction feels broken. If online counts are inaccurate, operations may misread live-room heat. If room state updates slowly, the viewer side may stay on the wrong screen.

These are not only UI problems. They are event propagation problems.

Events Need Boundaries

Not all live-room data should be pushed in realtime. Room configuration, user profile, and history records can use normal APIs. Comments, new messages, room state, and presence changes are better as events.

When I design this kind of capability, I first separate state query from event notification. Query emphasizes accuracy. Notification emphasizes timing. Mixing them makes the system hard to debug.

Presence Is a Business Concept

Presence looks like a technical feature, but in a live room it becomes a business concept.

Who entered, who left, how long a user has been silent, and whether they should still count as online all affect online counts and operations statistics. If I treat presence only as connection count, I miss many business details.

I prefer to design Presence as viewer state. Connection is only one signal. Heartbeat, cache, expiration cleanup, and room dimension all matter.

Admin Needs Realtime Feedback Too

Realtime capability is not only for the viewer side. Operations staff also need room state, comment activity, and online changes.

If the admin panel only updates after manual refresh, operations cannot judge problems quickly. When realtime events reach the admin side, staff can see whether the live room is healthy, whether comments are active, and whether online counts look abnormal.

This moves the system from "can stream" to "can operate".

Realtime Eventually Returns to Stability

The value of realtime live-room capability is not the name of the stack. It is stability.

Events should not be noisy, connections should not consume resources forever, offline state must be cleaned up, and comments and online statistics must be explainable. If the foundation is unstable, more realtime behavior only creates more problems.

So I treat realtime as a system capability: event model, connection management, cached state, admin feedback, and troubleshooting should be designed together, not as only one push channel.