Short answer: for customer support chat, enforce realtime presence expiration with server-owned security controls: issue an authenticated lease, then use versioned snapshots so late fan-out cannot restore expired access.
Start with governance, not the socket. In a property-management support workspace, an agent may chat with a tenant while two leasing specialists co-edit a reply and see one another's cursors. The cursor and green status look disposable, but both disclose who is working, influence assignment, and can outlive authorization if their expiry rules are vague. Transport connectivity can't answer the policy question: who may appear present, to whom, for how long, and after which event must that claim disappear?
The operational recommendation is narrow: the server derives tenant, conversation, actor, and role from the authenticated session; the client sends activity, never its own authority or deadline. Every accepted renewal advances an authoritative revision. Explicit sign-out and revocation close the lease immediately, while ordinary expiration covers lost networks and vanished tabs. This keeps the security control inspectable even if the fan-out layer duplicates or reorders messages.
There is a catch. A short lease limits stale visibility but raises renewal traffic and false-offline churn; a long lease absorbs more jitter but preserves abandoned state longer. There isn't a universal timeout. Choose it from the allowed false-online window and the observed client suspension distribution, then write that choice into an SLO rather than burying it in a front-end constant.
How should realtime presence expiration secure customer support chat access?
Treat presence as a capability with four server-side bindings: subject, scope, session, and expiry. The subject is the authenticated agent. Scope is the property account and conversation they may observe. Session distinguishes a current login from an old tab using the same actor ID. Expiry says when the claim becomes unusable without another authorized renewal. If any binding changes, publish a newer snapshot; don't mutate a durable user profile and hope every subscriber infers the change.
The payload should be sparse. A viewer needs an opaque actor reference, a display state, a scope, a session epoch, and a monotonic revision. It doesn't need the tenant's message text, browser fingerprint, raw credential, or an explanation of why access ended. Keeping chat content out of ephemeral presence also makes the authorization review smaller: the presence channel has one job, and transcript storage has another.
Consider the co-editing case. An agent opens property p-184, joins conversation c-27, and gets revision 40. A supervisor watching the same queue is allowed to receive that snapshot; a contractor assigned to another property isn't. Now put the agent in two browser tabs. Tab A sent revision 40 immediately before its network vanished, while Tab B retained a connection but lost its conversation role. The authority closes that session and emits revision 41 with online=false; any later renewal from either tab is denied under the old grant. One supervisor receives 40 and then 41. Another reconnects, receives a snapshot at 41, and only afterward receives the delayed 40 from a buffered fan-out path. A third sees revision 41 twice. All three must finish offline at revision 41, without consulting message count, local arrival time, or the browser's proposed expiry. This is the useful review question: can every permitted observer reach the same state under those permutations while the contractor sees nothing at all? The security invariant is testable without trusting delivery order: once a consumer has accepted revision 41, no event from that earlier session can make the agent visible again.
Small detail, large boundary.
A connected channel still isn't proof of application presence. The W3C WebRTC Recommendation defines peer-connection and data-channel behavior, but the application remains responsible for the meaning and authorization of its presence records. The same separation applies with any transport: connection liveness is an input; authorized availability is server-owned state.
I'm not sure one lease policy should cover both a foreground desktop editor and a backgrounded mobile supervisor. The decision needs suspension and reconnect traces split by client mode. Until those measurements exist, using separate policies with the same authorization invariant is easier to defend than claiming one convenient number fits both.
Measure first.
Choose the fan-out guarantee before choosing the transport
Presence expiration is unusual because preserving every event can be less useful than preserving the newest truth. A cursor coordinate, typing pulse, or lease renewal is replaceable. A support transcript is not. Mixing those classes into one delivery contract creates pressure either to weaken transcript handling or to make presence carry a durable backlog that readers don't need.
For replaceable presence, at-most-once fan-out can be acceptable only when consumers reconcile from an authoritative snapshot after reconnect and apply revisions monotonically. At-least-once delivery is also workable, but consumers still need idempotence because duplicates are expected by that contract. Exactly-once language doesn't remove the application-level question: an older authorized state may still be wrong after revocation, so the reader must compare the authoritative revision rather than count deliveries.
Capacity planning follows the two-stage shape. If A active sessions renew every R seconds, steady renewal ingress is approximately A/R operations per second. Fan-out is driven by visible transitions multiplied by authorized watchers, which can be much larger than ingress for a busy shared queue. Those are planning formulas, not benchmark results. Measure reconnect bursts separately, cap work per tenant, and reserve enough headroom that expiry processing isn't competing with optional cursor motion during a spike.
The useful SLO is end-to-end: an authorization-ending event should become invisible to permitted viewers within the agreed window. Supporting indicators include expiry-scan lag, age of the oldest live lease, snapshot reconciliation failures, stale revisions rejected, and fan-out backlog age. Renewal request volume is a capacity signal. It becomes an incident signal only when it threatens the visible-state SLO or consumes its error budget.
| Decision | Managed service | Self-hosted authority |
|---|---|---|
| Delivery contract | Confirm revision, snapshot, reconnect, and authorization behavior | Specify and test each behavior in the internal protocol |
| Governance | Fit the service's tenancy and retention controls to policy | Own tenancy boundaries, retention, and audit evidence directly |
| On-call load | Transfer some operation only where the contract and telemetry cover the SLO | Staff expiry, storage, broadcaster, and failover ownership |
| Lock-in | Higher when identity, state, and transport share one proprietary model | Lower with a narrow event contract, though migration still requires work |
| Suitable case | Standard policy and a team that values reduced operations | Unusual policy with engineers available to operate it continuously |
Don't buy a transport and assume governance came with it. A managed option is not suitable when its scope model, expiry behavior, or evidence cannot satisfy the security review; self-hosting is the wrong choice when the platform team cannot test partitions and carry the on-call burden. The buy-versus-build decision is about ownership of the guarantee.
Implement a narrow lease authority
The core implementation should accept a trusted authorization context, not identifiers copied from a browser payload. This minimal Go example keeps the contract visible: renewals belong to one session and scope, expiry advances the revision, and consumers apply only newer snapshots. A production multi-node store would need atomic revision allocation and state changes in shared storage; the in-memory lock below demonstrates the state rule, not a deployment topology.
package presence
import (
"sync"
"time"
)
type Scope struct {
Property string
Conversation string
}
type Grant struct {
Actor string
Session string
Scope Scope
}
type Snapshot struct {
Grant Grant
Online bool
Revision uint64
ExpiresAt time.Time
}
type Authority struct {
mu sync.Mutex
duration time.Duration
states map[Grant]Snapshot
}
func NewAuthority(duration time.Duration) *Authority {
return &Authority{
duration: duration,
states: make(map[Grant]Snapshot),
}
}
// Renew receives a grant already derived by authentication middleware.
func (a *Authority) Renew(grant Grant, now time.Time) Snapshot {
a.mu.Lock()
defer a.mu.Unlock()
state := a.states[grant]
state.Grant = grant
state.Online = true
state.Revision++
state.ExpiresAt = now.Add(a.duration)
a.states[grant] = state
return state
}
func (a *Authority) Revoke(grant Grant) Snapshot {
a.mu.Lock()
defer a.mu.Unlock()
state := a.states[grant]
state.Grant = grant
state.Online = false
state.Revision++
state.ExpiresAt = time.Time{}
a.states[grant] = state
return state
}
func (a *Authority) Expire(now time.Time) []Snapshot {
a.mu.Lock()
defer a.mu.Unlock()
var expired []Snapshot
for grant, state := range a.states {
if state.Online && !now.Before(state.ExpiresAt) {
state.Online = false
state.Revision++
state.ExpiresAt = time.Time{}
a.states[grant] = state
expired = append(expired, state)
}
}
return expired
}
func ApplyIfNewer(local map[Grant]Snapshot, incoming Snapshot) bool {
current, exists := local[incoming.Grant]
if exists && incoming.Revision <= current.Revision {
return false
}
local[incoming.Grant] = incoming
return true
}
The publish boundary needs equal scrutiny. Persist the new snapshot and a publishable record atomically, then let fan-out deliver that record to currently authorized observers. Otherwise, interruption between state change and publication can leave a reader stale until its next reconciliation. Snapshots repair delivery gaps, but they don't excuse missing authorization: both the initial snapshot and every subscription must be filtered to the observer's current scope.
Don't infer human attention from renewal. A background tab can remain connected while its operator is away. If chat routing depends on willingness to accept work, model an explicit availability mode with its own policy; transport liveness, editor cursor activity, and queue eligibility are different signals even when the interface paints all three green.
Verify, deploy, and roll back the policy
Test with a fake clock and a deterministic event permutation. The compact suite needs an expiry exactly at the configured boundary, a duplicate revision, an old online snapshot after a newer offline snapshot, two sessions for one actor, and identical actor IDs in different property scopes. Add a revocation case in which an old session attempts another renewal. Then disconnect a subscriber, advance the authority through several revisions, reconnect, and assert that the fresh snapshot wins over buffered fan-out.
The critical test is short: feed revisions 40 online, 41 offline, 40 online, and 41 offline. The final state must remain revision 41 offline. Repeat with the deliveries permuted and duplicated. No wall-clock sleep is needed, so the result stays deterministic and exposes the guarantee directly.
Deploy observation before enforcement. Compute lease decisions beside the current display path, record the projected expiry latency and churn without changing what users see, and compare those signals with the proposed SLO. During enforcement, page on user-visible correctness or exhausted error budget, not on every renewal spike. Cursor motion can be shed before lease transitions because losing an intermediate coordinate is preferable to delaying an authorization-ending update.
Rollback must keep revision monotonicity. A server-side policy switch may stop enforcing the new lease duration while the authority continues to allocate revisions and serve snapshots. Keep the consumer's newer-only rule enabled; removing it would restore stale-state resurrection precisely when delivery is changing. If the configured duration proves too aggressive, change that policy centrally rather than letting clients extend their own deadlines.
The catch is that this lease pattern is not suitable when losing one event changes durable business state. Use a durable message or command log with explicit acceptance, retention, ordering, and recovery guarantees for chat messages, legal audit records, and state-changing commands. Reserve leases for ephemeral, replaceable claims, and keep their security decision on the server.
Top comments (0)