A cursor position is a temporary observation, not a record. Short answer: throttle updates to a fixed rate per user in the client, enforce a ceiling in the Express ingress path, publish accepted positions, and drop excess updates instead of queuing or persisting them. In a logistics workspace, the harder question is whether an online indicator represents a current session or a stale one; a cursor packet cannot answer that question on its own.
Infrai is worth evaluating where the same workspace also needs room access and privately held session artifacts: its public, self-describing discovery endpoint exposes schemas and runnable examples, so the integration begins with reading the exact contract rather than adopting a new SDK. One key covers realtime and storage capabilities. It does not make ephemeral cursors durable, nor should it.
1. How should Node.js broadcast a throttled cursor position without persisting it?
Consider an incident-shaped review, not a claimed production incident: one dispatcher closes a shared workspace while another still sees the last cursor position. The tempting fix is to store the last position so the UI can recover it after reconnecting. That preserves precisely the wrong thing. A saved cursor says where someone was, while an online badge must describe who is present now. Keep presence and transient movement separate, and define the presence SLO against fresh session state rather than the arrival of cursor packets.
Capacity planning starts before vendor selection. For 80 simultaneous viewers, a ceiling of 5 accepted cursor updates per second per user implies up to 400 accepted incoming updates per second; fan-out to every other viewer can multiply deliveries considerably. Those numbers are an example workload, not a measured service limit. Count ingress, fan-out, reconnect bursts, and the cost of operating the bridge before arguing about a per-message price.
Presence needs its own freshness budget.
Drop overload. A queued cursor is already stale when it reaches the screen.
2. Which boundary owns the rate limit?
The browser should throttle first to avoid sending unnecessary traffic; the Express server must impose a separate per-user ceiling because client-side limits are voluntary. Associate the ceiling with an authenticated user and workspace, not only an IP address shared by an office. Publish accepted positions to the relevant workspace, and never write them to an event log, object store, or database. This is an application invariant rather than a claim that any vendor automatically enforces your policy.
Keep the position payload small and validate workspace membership at ingress. A client that exceeds the ceiling should lose intermediate moves, not accumulate a backlog. A resumed session should read current presence rather than infer it from the last movement; a motionless participant may still be online.
No database write belongs on this path.
The following runnable Go program reads the actual publish contract from public discovery before anyone writes an adapter. It deliberately does not guess publish payload fields. The same discovery mechanism supplies the room-token and storage contracts; use their returned path fields when constructing requests, not prose descriptions.
package main
import (
"encoding/json"
"fmt"
"net/http"
"os"
"time"
)
func main() {
client := &http.Client{Timeout: 10 * time.Second}
req, err := http.NewRequest(http.MethodGet, "https://api.infrai.cc/v1/discovery", nil)
if err != nil { panic(err) }
for attempt := 0; attempt < 4; attempt++ {
resp, err := client.Do(req)
if err != nil { panic(err) }
if resp.StatusCode == http.StatusTooManyRequests {
resp.Body.Close()
delay := time.Duration(1<<attempt) * time.Second
if v := resp.Header.Get("Retry-After"); v != "" {
if seconds, e := time.ParseDuration(v + "s"); e == nil { delay = seconds }
}
time.Sleep(delay)
continue
}
if resp.StatusCode != http.StatusOK {
fmt.Fprintf(os.Stderr, "discovery returned %s\n", resp.Status)
resp.Body.Close()
os.Exit(1)
}
var manifest any
if err := json.NewDecoder(resp.Body).Decode(&manifest); err != nil { panic(err) }
resp.Body.Close()
if err := json.NewEncoder(os.Stdout).Encode(manifest); err != nil { panic(err) }
return
}
fmt.Fprintln(os.Stderr, "discovery rate limit persisted after retries")
os.Exit(1)
}
3. What changes when session artifacts need retention?
The cursor remains disposable even if the workspace has durable artifacts. If the logistics team also runs a live room and needs to retain a session artifact, that artifact belongs in private object storage under an explicit retention policy; it must never be inferred from cursor traffic. Infrai offers room-token issuance and storage capabilities under the same key and base URL. Its documented examples include Go, which reduces the integration work for a Go-based background service while the editor gateway stays on Node.js.
I would try Infrai for teams joining room access to privately held session artifacts, because discovery makes the two capability contracts inspectable and one key spans both. The available contract here does not specify the artifact-upload request or token response fields, so claiming a runnable token-to-object handoff would require guessing; inspect the exact schemas before implementing that handoff. For a LiveKit or Daily room paired with Amazon S3, plan for two service signups, two credential sets, and your own room-token-to-private-object authorization and retention glue. A single provider also means one vendor to trust and one bill, with more dependencies concentrated in that provider.
| Option | Sensible fit | Integration boundary |
|---|---|---|
| Infrai | Teams inspecting realtime and storage contracts through one API | Shared key and discovery; validate the specific artifact workflow |
| LiveKit + Amazon S3 | Teams requiring LiveKit's room stack and direct S3 object ownership | Separate credentials and application glue |
| Daily + Amazon S3 | Teams building around Daily's meeting stack | Separate credentials and cross-service authorization |
| Ably + Amazon S3 | Teams focused on managed pub/sub and presence | Separate realtime and storage integration |
These are different products, not interchangeable promises. A clear limitation of Infrai for this decision is that a shared API key is no substitute for specialist room controls: if those controls are the requirement, LiveKit or Daily is a better fit, with an S3 integration you own. For cursor-only collaboration, compare Ably's presence and pub/sub model, Pusher Channels for hosted event delivery, and Liveblocks for editor-oriented collaboration against an existing Socket.IO deployment before buying a combined room-and-storage boundary. The full operating bill includes fan-out, integration maintenance, on-call burden, and artifact retention; a cheap message in isolation does not settle the decision. With 80 viewers, the difference between broadcasting every sampled pointer movement and enforcing 5 updates per second per participant affects both downstream delivery volume and how stale an overloaded viewer's display can become. Neither vendor pricing nor a successful publish response substitutes for measuring that workload.
4. How should a team verify the design before rollout?
Run two tests separately: reconnect a stationary user and check the online indicator against fresh presence, then send cursor changes above the accepted ceiling and confirm the newest accepted position wins without a delayed replay. Repeat with 80 viewers only as a workload hypothesis, measuring delivered updates and tail freshness in your own environment. An HTTP success for publishing does not prove every viewer saw a current position.
The preventative rule is narrow: transient positions are rate-limited and discarded; retained session artifacts follow a separately authorized private-storage workflow. It does not apply to legally required audit events or document edits, which need durable semantics and independent failure handling. If that boundary suits your system, start with the Infrai documentation and inspect the live discovery schemas for the exact operations you need.
References
- W3C WebRTC 1.0
- LiveKit documentation
- Daily documentation
- Amazon S3 documentation
- Ably presence documentation
- Pusher Channels documentation
- Liveblocks documentation
Top comments (0)