Cap presence fan-out per room without silently losing state
A synthetic busy room causes unbounded socket buffers. Introduce a per-client queue cap and resync fallback.
- Focused work estimate
- 3h + prerequisites
- Priority in the scenario
- Medium
- Engineering practice
- Backpressure · Resource limits
Estimated field mix
- Performance engineering50%
- Real-time systems30%
- Site reliability20%
Field percentages are editorial estimates of the ticket's engineering focus. They total 100%; they are not measured time, proficiency scores, or ownership evidence.
Review it, then add it to your workspace.
The board opens an editable draft; nothing is saved until you confirm it. Sign-in and workspace permissions apply, and Demo boards remain ephemeral.
Project context
Fictional document team Pine shows collaboration presence for synthetic accounts. Build a loopback WebSocket server and injected clocks; no message content or activity surveillance is required.
Setup prerequisites
- Create synthetic memberships and session identifiers.
- Implement controllable sockets and an in-memory TTL adapter.
Preceding work
Complete these dependencies, or supply their agreed outputs before taking this ticket.
- CPRES-101 · Define online presence as an unexpired connection lease
- CPRES-102 · Validate presence room identifiers before subscribing
- CPRES-103 · Scope presence membership checks to each room subscription
- CPRES-104 · Count multiple presence connections without duplicating people
- CPRES-105 · Reject stale presence heartbeats after reconnect
- CPRES-106 · Send a presence snapshot before incremental updates
Acceptance criteria
- Buffer count is bounded
- Overflow requests resnapshot
- Healthy peers continue receiving
Implementation constraints
- Do not drop arbitrary deltas and claim synchronization.
Verification to include
- Exercise normal fan-out
- Stall one client to capacity
Deliverables
- Bounded broadcaster and overflow cases
Rollout and recovery
Disconnect slow clients with a clear resync reason.
Value of the work
For the engineer: Practice ephemeral state, ordering and reconnect semantics.
For the team: Inspect whether online indicators avoid stale or unauthorized claims.
Evidence boundaries
Outcome Evidence: Tests, patches, and runbooks are requested deliverables. They become Outcome Evidence only through a qualified Mission and immutable Evidence IDs.
Ownership Evidence: Independent adaptation must be observed under a declared verification policy and cite immutable Evidence IDs. Completing a planning ticket establishes no Ownership Evidence.