VividEcho runs multiple API instances behind the scenes for reliability and scale — which raises an obvious question: how does a change made through one instance reach the others? VividEcho answers that with an internal fan-out channel built on SignalR over a Service Bus, keeping every running instance consistent with the platform's current configuration.
This mechanism is purely internal coordination between VividEcho's own components — it isn't a client-facing real-time data feed, and application data changes aren't broadcast to your frontend through it. When the Management Console adds or changes an application, it publishes that change so every API instance reloads and picks up the new configuration, rather than leaving the instances that didn't handle the original request serving stale settings. The same channel is used to broadcast operational signals, such as turning on local telemetry across every instance at once.
In short: this is the plumbing that keeps a multi-instance deployment of VividEcho itself in sync, not a subscription mechanism for your app's documents.
If you're familiar with SignalR, the connection code below shows the general shape of subscribing to a hub — it's included here as an illustrative example of that syntax rather than a documented client-facing endpoint you can rely on today.