[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill-microsoft-system-type-real-time":3,"mdc-7yae4j-key":33,"related-repo-microsoft-system-type-real-time":1267,"related-org-microsoft-system-type-real-time":1350},{"slug":4,"name":4,"fn":5,"description":6,"org":7,"tags":11,"stars":22,"repoUrl":23,"updatedAt":24,"license":25,"forks":26,"topics":27,"repo":28,"sourceUrl":31,"mdContent":32},"system-type-real-time","design real-time and collaborative systems","Domain patterns for real-time and collaborative systems — persistent connections, state synchronization, conflict resolution, presence, fan-out, and failure modes. Use when designing or evaluating chat systems, collaborative editors, live dashboards, gaming backends, or any system with bidirectional real-time communication.",{"slug":8,"name":9,"logoUrl":10,"githubOrg":8},"microsoft","Microsoft","https:\u002F\u002Fpexgzepcugksgbtrxkhf.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Forg-logos\u002Fmicrosoft.png",[12,16,19],{"name":13,"slug":14,"type":15},"Architecture","architecture","tag",{"name":17,"slug":18,"type":15},"System Design","system-design",{"name":20,"slug":21,"type":15},"Real-time","real-time",0,"https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Famplifier-bundle-systems-design","2026-07-07T06:53:26.004577",null,1,[],{"repoUrl":23,"stars":22,"forks":26,"topics":29,"description":30},[],"Systems-design capabilities for Amplifier sessions.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Famplifier-bundle-systems-design\u002Ftree\u002FHEAD\u002Fskills\u002Fsystem-type-real-time","---\nname: system-type-real-time\ndescription: \"Domain patterns for real-time and collaborative systems — persistent connections, state synchronization, conflict resolution, presence, fan-out, and failure modes. Use when designing or evaluating chat systems, collaborative editors, live dashboards, gaming backends, or any system with bidirectional real-time communication.\"\n---\n\n# System Type: Real-Time & Collaborative\n\nPatterns, failure modes, and anti-patterns for systems with persistent connections and real-time state synchronization.\n\n---\n\n## Connection Patterns\n\n### WebSocket\n**What it is.** Full-duplex, persistent TCP connection upgraded from HTTP. Both sides can send frames at any time.\n**When to use.** Bidirectional communication with low latency — chat, collaborative editing, multiplayer games, live trading. When the server needs to push AND the client needs to push back frequently.\n**When to avoid.** Unidirectional server-to-client updates (SSE is simpler). Infrequent updates where polling is adequate. Environments where intermediaries (corporate proxies, older load balancers) silently kill long-lived connections.\n**Key decisions.** Binary vs text frames, subprotocol negotiation, per-message compression (permessage-deflate has CPU cost), ping\u002Fpong interval tuning.\n\n### Server-Sent Events (SSE)\n**What it is.** Unidirectional server-to-client stream over a standard HTTP response. Built-in reconnection with `Last-Event-ID`. Works through HTTP\u002F2 multiplexing natively.\n**When to use.** Live dashboards, notification feeds, stock tickers — anything where the server pushes and the client only needs HTTP requests for writes. When you want automatic reconnection semantics for free.\n**When to avoid.** Bidirectional real-time communication. Binary data. When you need more than ~6 concurrent connections per domain in HTTP\u002F1.1 browsers (HTTP\u002F2 eliminates this).\n\n### Long Polling\n**What it is.** Client sends a request; server holds it open until there's data or a timeout, then responds. Client immediately sends the next request.\n**When to use.** Fallback when WebSocket and SSE aren't available. Environments with aggressive proxies. When connection frequency is low enough that the overhead is acceptable.\n**When to avoid.** High-frequency updates (each message requires a full HTTP round-trip). The per-request overhead is substantial compared to persistent connections.\n\n### WebTransport\n**What it is.** Multiplexed, bidirectional transport built on HTTP\u002F3 (QUIC). Supports both reliable streams and unreliable datagrams. No head-of-line blocking.\n**When to use.** Latency-sensitive applications where packet loss shouldn't stall unrelated streams — gaming, live media, telemetry. When you need unreliable delivery (datagrams) alongside reliable streams.\n**When to avoid.** Browser support is still limited. When WebSocket meets your latency requirements. When you don't control the server infrastructure to support HTTP\u002F3.\n\n### Connection Lifecycle\nEvery persistent connection follows the same pattern: **establish → authenticate → maintain → recover**.\n\n- **Establish.** Negotiate the connection (WebSocket upgrade, SSE stream open). Set initial parameters. The handshake is your one chance to reject bad clients cheaply.\n- **Authenticate.** Pass a short-lived token during handshake (query param or first message). Never rely on cookies alone — CSRF is harder to prevent on WebSocket upgrades. Re-validate tokens periodically for long-lived connections.\n- **Heartbeat.** Both sides send pings at a regular interval. If a pong is missed, the connection is considered dead. Tune the interval: too fast wastes bandwidth; too slow means minutes of stale \"online\" state. 30 seconds is a common default; 15 seconds for presence-critical systems.\n- **Reconnect.** Exponential backoff with jitter. Include the last-seen sequence number so the server can resume without replaying the entire state. Cap the backoff (e.g., 60 seconds) — waiting 10 minutes to reconnect is indistinguishable from being offline.\n\n### Connection Multiplexing\nMultiple logical channels over a single physical connection. Avoids the cost of many TCP handshakes and TLS negotiations. Implement with message framing that includes a channel ID. Watch for: head-of-line blocking in WebSocket (a single TCP stream), priority inversion between channels, complexity of flow control per logical channel.\n\n## State Synchronization\n\n### Server-Authoritative State\n**What it is.** The server owns the truth. Clients send intents; the server validates, applies, and broadcasts the result.\n**When to use.** Any system where correctness matters more than perceived latency — financial systems, competitive games, inventory management. When cheating or inconsistency is unacceptable.\n**The cost.** Every action has at least one round-trip of latency before the user sees the result.\n\n### Optimistic Updates with Server Reconciliation\n**What it is.** Client applies changes locally before server confirmation. If the server rejects or modifies the change, the client rolls back or reconciles.\n**When to use.** Collaborative editing, chat message sending, any UI where perceived latency matters. The user sees their action instantly; corrections arrive later.\n**The hard part.** Rolling back user-visible state is jarring. Design for reconciliation (merge the server's response into local state) rather than rollback (undo and redo). The client must maintain a queue of unconfirmed changes and be able to rebase them onto server state.\n\n### Client Prediction\n**What it is.** Client simulates the outcome of actions locally and reconciles when the server's authoritative state arrives. Common in games (client-side prediction with server reconciliation).\n**When to use.** Real-time games, cursor tracking, any interaction where the round-trip latency is perceptible and the outcome is usually predictable.\n**Watch for.** Mispredictions cause visual corrections (\"rubber-banding\"). The prediction logic must match server logic exactly, or divergence accumulates.\n\n### Operational Transformation (OT)\n**What it is.** Transforms concurrent operations against each other so they can be applied in any order and converge to the same state. Requires a central server to determine operation ordering.\n**When to use.** Text-based collaborative editing (Google Docs uses OT). When you have a reliable central server and need character-level collaboration.\n**When to avoid.** Decentralized systems (OT requires a single ordering authority). Complex data structures beyond text — OT transform functions become combinatorially complex as operation types grow.\n\n### CRDTs (Conflict-Free Replicated Data Types)\n**What it is.** Data structures where concurrent updates always converge without coordination. No central server needed for correctness — peers can sync directly.\n**When to use.** Offline-capable collaboration, peer-to-peer systems, any system where nodes must work independently and sync later. Text editing (Yjs, Automerge), shared counters, sets, maps.\n**When to avoid.** When server-authoritative state is simpler and sufficient. CRDTs have memory overhead (they carry metadata for conflict resolution) and some types (text sequences) are significantly more complex to implement correctly than OT. When your data model doesn't map cleanly to available CRDT types.\n\n### Versioning and Ordering\n**Sequence numbers.** Simple monotonic counter per stream. Sufficient for single-server systems. Clients can detect gaps and request retransmission.\n**Vector clocks.** Track causal ordering across multiple nodes. Each node maintains a counter per known node. Expensive to compare at scale — the vector grows with the number of participants.\n**Hybrid logical clocks.** Combine physical timestamps with logical counters. More compact than vector clocks, provide causal ordering, and approximate wall-clock time. Good for distributed collaborative systems.\n**Lamport timestamps.** Provide total ordering but not causal ordering. Sufficient when you just need a tiebreaker, not true causality tracking.\n\n## Conflict Resolution\n\n### Last-Writer-Wins (LWW)\n**What it is.** Most recent write (by timestamp or version number) wins. Previous concurrent writes are silently discarded.\n**When to use.** User profile updates, settings, any field where the most recent intent is what matters and losing a concurrent write is acceptable.\n**When to avoid.** Anything additive (counters, lists, collaborative text). Losing a write silently is data loss — LWW just makes it someone else's problem.\n\n### Application-Level Merge Strategies\n**When conflicts are acceptable.** Most collaborative systems — two users editing different paragraphs, updating different fields. Present both versions and let the user choose, or merge automatically when the changes are non-overlapping.\n**When conflicts are catastrophic.** Financial transactions, inventory reservation, anything where \"both writes happen\" means real-world harm. Use pessimistic locking, serializable transactions, or compare-and-swap operations. Accept the latency cost.\n\n### CRDT Conflict Resolution\n- **G-Counter \u002F PN-Counter.** Grow-only and positive-negative counters. Each node increments its own slot. Sum of all slots is the value. No conflicts possible by construction.\n- **G-Set \u002F OR-Set.** Grow-only set (add-only) and observed-remove set (add and remove). OR-Set handles the \"add wins over concurrent remove\" semantic, which is the right default for most applications.\n- **LWW-Register.** Last-writer-wins register using timestamps. Simple but lossy — use when losing concurrent writes is tolerable.\n- **Text CRDTs (RGA, YATA).** Represent text as a sequence of uniquely identified characters with ordering metadata. Insertions and deletions commute. Libraries like Yjs and Automerge implement these. Memory overhead is real — a 10KB document may use 100KB+ of CRDT metadata.\n\n## Presence and Awareness\n\n### Online\u002FOffline Detection\n**Heartbeat-based presence.** Client sends periodic heartbeats. Server marks client as offline after missing N consecutive heartbeats. Simple and reliable. Tune the timeout: too aggressive and flaky connections cause presence flickering; too lenient and stale presence lingers for minutes.\n**The fundamental tradeoff.** Fast detection (5-10s timeout) vs stable presence (30-60s timeout). Chat applications typically use 15-30 seconds. Collaborative editors can tolerate 30-60 seconds because the cursor position already conveys activity.\n\n### Cursor Positions and Selection\nBroadcast cursor position on change, throttled to ~10-20 updates per second per user. Include a user identifier and color. Don't broadcast every keystroke position — batch and throttle. For remote cursors, interpolate between received positions to smooth movement.\n\n### Typing Indicators\nSend a \"started typing\" event. Clear after a timeout (3-5 seconds of inactivity) or an explicit \"stopped typing\" event. Don't send continuous \"is typing\" events — send transitions. Rate-limit outbound typing events to avoid flooding channels with many participants.\n\n### Thundering Herd on Reconnection\nWhen a server restarts or a network partition heals, all clients reconnect simultaneously. Every client sends presence updates, subscribes to channels, and requests state catch-up — at the same instant.\n**Mitigations:**\n- **Jittered reconnect delay.** Clients wait a random interval (0 to N seconds) before reconnecting. Spreads the thundering herd across a time window.\n- **Gradual presence broadcast.** After a server restart, don't broadcast all presence updates immediately. Batch and stagger.\n- **Connection rate limiting.** Accept connections at a controlled rate. Return \"retry later\" with a backoff hint for excess connections.\n- **Stale presence TTL.** Don't immediately mark everyone as offline when a server restarts. Assume recent presence is still valid for a short window while clients reconnect.\n\n## Fan-Out Patterns\n\n### Per-Connection Fan-Out\n**What it is.** For each message, iterate over all connected clients and deliver individually.\n**When to use.** Small-scale systems, prototypes, rooms with fewer than ~100 participants.\n**When it breaks.** Delivery time grows linearly with connection count. A room with 10,000 members means 10,000 individual sends per message. CPU and memory on the connection server become the bottleneck.\n\n### Channel-Based Routing\n**What it is.** Clients subscribe to named channels (rooms, topics). Messages published to a channel are delivered to all subscribers. The pub\u002Fsub layer handles fan-out.\n**When to use.** Chat rooms, topic-based feeds, any system with natural groupings of interested clients.\n**Implementation.** In-process subscriber lists for single-server. Redis Pub\u002FSub, NATS, or Kafka for multi-server. The pub\u002Fsub layer must deliver to every server that has subscribers for the channel; each server then fans out to its local connections.\n\n### Presence-Aware Delivery\n**What it is.** Only deliver to clients that are currently online. Queue or drop messages for offline clients based on policy.\n**When to use.** Systems where offline delivery is handled separately (push notifications, email fallback) or where messages are ephemeral (typing indicators, cursor positions).\n**The decision.** What happens to messages for offline users? Options: drop silently (ephemeral data), queue for delivery on reconnect (chat messages), persist and let client pull on reconnect (channel history).\n\n### The N-Squared Problem\nIn a room with N participants, each participant's state change (cursor move, typing indicator) must be sent to N-1 others. That's O(N) messages per event, and if all N participants are active, that's O(N²) messages per second. At ~50 participants, this dominates bandwidth.\n**Mitigations:**\n- **Throttle per-user broadcasts.** Limit cursor updates to 5-10 per second per user regardless of actual movement frequency.\n- **Viewport-aware fan-out.** Only send updates relevant to what each client is viewing. A user viewing page 1 doesn't need cursor positions from page 47.\n- **Aggregated updates.** Batch multiple small updates into a single message per delivery interval (e.g., every 50ms). Reduces message count at the cost of slight latency.\n- **Tiered presence.** Full presence for focused collaborators; degraded presence (online\u002Foffline only) for observers.\n\n### Scaling Fan-Out\n\n**Pub\u002FSub backing.** Use Redis Pub\u002FSub, NATS, or Kafka to distribute messages across connection servers. Each connection server subscribes to channels that its local clients care about. Watch for: Redis Pub\u002FSub is fire-and-forget (no persistence, no replay); Kafka provides persistence but adds latency; NATS JetStream provides a middle ground.\n\n**Connection affinity.** Route clients in the same channel to the same connection server when possible. Reduces cross-server fan-out. Watch for: uneven distribution when some channels are much larger than others, rebalancing during deploys.\n\n**Sharded channels.** For very large channels (thousands of subscribers), shard across multiple servers. Each shard handles fan-out for a subset of subscribers. A message published to the channel is forwarded to all shards. Watch for: ordering guarantees across shards, shard rebalancing.\n\n## Reconnection and Rehydration\n\n### Resumable Connections\nAssign each connection a session ID and track the last-delivered sequence number. On reconnect, the client sends its session ID and last-seen sequence number. The server replays missed messages from a buffer.\n**Buffer sizing.** Too small and clients that were offline for a minute get a full resync. Too large and the server holds too much state per connection. A sliding window of 5-10 minutes of messages is typical. Use a ring buffer per channel, not per connection.\n\n### State Catch-Up After Disconnect\n**Delta sync.** Client sends its last-known version. Server computes and sends only the changes since that version. Efficient but requires the server to maintain a change log.\n**Full sync.** Client discards local state and downloads everything. Simple but expensive. Acceptable for small state (a chat room's last 50 messages); unacceptable for large state (a collaborative document).\n**Hybrid.** Attempt delta sync. If the client's version is too old (outside the change log window), fall back to full sync. This is the pragmatic approach for most systems.\n\n### Offline Queue\nClient queues actions performed while disconnected. On reconnect, the queue is replayed against the server.\n**The hard part.** Actions in the queue may conflict with changes made by other users while this client was offline. Each queued action must be validated and potentially transformed or rejected by the server. This is where OT and CRDTs earn their complexity budget — they provide principled answers to \"what happens when I replay my offline edits against a state that has moved on.\"\n\n## Scaling Persistent Connections\n\n### Connection Servers vs Application Servers\nSeparate the concern of holding connections from the concern of processing business logic. Connection servers are I\u002FO-bound (thousands of idle connections, occasional message forwarding). Application servers are CPU-bound (message validation, persistence, business rules). Scaling them independently is the key to cost-efficient real-time systems.\n\n### Sticky Sessions and Their Downsides\nPersistent connections are inherently sticky — they're bound to the server that accepted the upgrade. This creates problems:\n- **Uneven load.** Some servers accumulate more connections over time, especially for popular channels.\n- **Deploys require draining.** You can't just kill a server — you must drain connections gracefully, giving clients time to reconnect elsewhere.\n- **Server failure is localized.** When a connection server dies, all its clients disconnect simultaneously, creating a localized thundering herd on the remaining servers.\n- **No mid-connection rebalancing.** Unlike HTTP requests, you can't redistribute persistent connections without client cooperation.\n\n### Connection Migration During Deploys\n**Graceful drain.** Stop accepting new connections. Send a \"please reconnect\" control message to existing clients with a jittered delay. Wait for connections to close. Shut down.\n**Blue\u002Fgreen for WebSocket.** Route new connections to the new deployment. Drain old connections over minutes, not seconds. The overlap period means both old and new servers must handle the same channels.\n**The deploy budget.** If you have 100,000 connections and each reconnection takes 100ms of server time, draining all connections simultaneously requires 10,000 seconds of CPU-time. Stagger over 2-5 minutes minimum.\n\n### Backpressure for Slow Consumers\nA client on a poor network connection can't receive messages as fast as they're produced. Without backpressure, the server buffers messages per-connection, memory grows, and the server eventually OOMs.\n**Strategies:**\n- **Per-connection send buffer with a cap.** If the buffer is full, drop messages (with a \"you missed N messages, resync\" notification) or disconnect the client.\n- **Priority-based dropping.** Drop ephemeral messages (cursor positions, typing indicators) before durable messages (chat content). Not all messages are equal.\n- **Adaptive rate.** Reduce update frequency for slow consumers. Send aggregated updates instead of individual events.\n\n### Memory Per Connection at Scale\nEach WebSocket connection costs memory: TCP buffers (~4-8KB), TLS state (~20-50KB), application-level state (subscriptions, session data). At 100,000 connections, that's 2-6GB of overhead before any message buffering. Budget for it. Monitor RSS per connection server. A \"small\" memory leak of 1KB per connection per hour becomes 100MB\u002Fhour at scale.\n\n## Common Failure Modes\n\n- **Connection storm on deploy.** Server restart disconnects all clients. They all reconnect simultaneously, overwhelming the new server before it's warmed up. Mitigation: jittered reconnect with exponential backoff, connection rate limiting on the server, pre-warming the new server before draining the old one.\n- **Slow consumer backpressure.** A client on a degraded network stops reading. The server buffers outbound messages. Multiply by thousands of slow clients and the server runs out of memory. Mitigation: per-connection buffer limits, drop policy for ephemeral messages, disconnect chronically slow consumers.\n- **Split-brain in presence.** Two servers disagree about who is online — one thinks the user connected, the other hasn't received the disconnect. Mitigation: presence TTL with heartbeat renewal, criss-cross presence queries during ambiguity, accept that presence is eventually consistent and design the UI accordingly.\n- **Message ordering across shards.** Messages published to different shards of a channel arrive at clients in different orders. Mitigation: include a causal ordering field (sequence number or timestamp) and let the client reorder. Accept that total ordering across shards is expensive and usually unnecessary.\n- **Thundering herd on network partition heal.** A network partition between data centers heals. Thousands of connections that were in \"reconnecting\" state all succeed at once. Both data centers flood each other with state sync. Mitigation: jittered reconnection, rate-limited sync, partition-aware message deduplication.\n- **Memory leaks from abandoned connections.** Client process crashes without sending a close frame. The server holds the connection open until the next heartbeat timeout. If heartbeats are infrequent or the cleanup path has bugs, connections accumulate. Mitigation: aggressive heartbeat timeouts (30s), periodic connection audits, process-level memory monitoring with alerts.\n- **Fan-out amplification.** A single message to a large channel generates thousands of outbound messages. If the channel has 50,000 subscribers across 100 servers, one inbound message becomes 50,000 outbound messages. Mitigation: sharded fan-out, hierarchical pub\u002Fsub (edge servers aggregate), rate limiting per-channel publish.\n- **Stale state after long disconnect.** Client reconnects after being offline for hours. The delta sync window has expired. The client has a deeply stale local state and applies offline changes against it. Mitigation: version-aware reconnection that detects when delta sync is impossible and forces full resync, discard offline queue when the gap is too large.\n\n## Anti-Patterns\n\n- **Polling in a WebSocket.** Opening a WebSocket and then having the client poll for updates on it every N seconds. You have a persistent connection — use server push. If you're polling, you didn't need WebSocket.\n- **Unbounded per-connection buffers.** Buffering all messages for every slow client without limits. One degraded mobile client on a busy channel can consume gigabytes of server memory. Always cap buffers and have a drop or disconnect policy.\n- **Presence as ground truth.** Treating presence state as strongly consistent. Presence is inherently best-effort — network delays, heartbeat windows, and race conditions mean presence will occasionally be wrong. Design the application to tolerate showing a user as online for 30 seconds after they left. Never make authorization decisions based on presence.\n- **Synchronous persistence in the message path.** Writing every message to a database before delivering to subscribers. This puts database latency in the critical path of every real-time message. Deliver first, persist asynchronously. Accept the small window of potential message loss or use a write-ahead log.\n- **Global ordering for everything.** Requiring total ordering across all messages in the system. Total ordering requires a single sequencer — a bottleneck by design. Most applications only need ordering within a channel or conversation. Identify where ordering actually matters and scope it narrowly.\n- **Reconnecting without backoff.** Client immediately retries on disconnect, in a tight loop. Multiplied across thousands of clients hitting a struggling server, this turns a transient failure into a permanent one. Always use exponential backoff with jitter. Always.\n- **Treating WebSocket connections as cheap.** Opening a connection per feature (one for chat, one for notifications, one for presence). Each connection has TLS, TCP, and memory overhead. Multiplex logical channels over a single connection. One connection per client, not per feature.\n- **CRDTs for everything.** Reaching for CRDTs because they sound elegant when server-authoritative state with simple last-writer-wins would suffice. CRDTs have real memory and complexity costs. Use them when you need offline-capable collaboration or decentralized sync. Use simpler models when you don't.\n- **Ignoring the deploy problem.** Designing the real-time system without a plan for zero-downtime deploys. Persistent connections make deploys fundamentally harder than stateless HTTP services. If you haven't designed graceful drain and reconnection, your first deploy under load will teach you why you should have.\n",{"data":34,"body":35},{"name":4,"description":6},{"type":36,"children":37},"root",[38,47,53,57,64,71,103,109,139,145,166,172,193,199,211,256,262,267,273,279,301,307,329,335,357,363,384,390,411,417,448,454,460,481,487,504,510,553,559,565,582,588,593,599,604,610,620,663,669,675,697,703,725,731,753,759,768,811,817,827,837,847,853,859,871,877,901,907,918,924,930,935,941,946,989,995,1019,1025,1035,1068,1074,1079,1085,1168,1174],{"type":39,"tag":40,"props":41,"children":43},"element","h1",{"id":42},"system-type-real-time-collaborative",[44],{"type":45,"value":46},"text","System Type: Real-Time & Collaborative",{"type":39,"tag":48,"props":49,"children":50},"p",{},[51],{"type":45,"value":52},"Patterns, failure modes, and anti-patterns for systems with persistent connections and real-time state synchronization.",{"type":39,"tag":54,"props":55,"children":56},"hr",{},[],{"type":39,"tag":58,"props":59,"children":61},"h2",{"id":60},"connection-patterns",[62],{"type":45,"value":63},"Connection Patterns",{"type":39,"tag":65,"props":66,"children":68},"h3",{"id":67},"websocket",[69],{"type":45,"value":70},"WebSocket",{"type":39,"tag":48,"props":72,"children":73},{},[74,80,82,87,89,94,96,101],{"type":39,"tag":75,"props":76,"children":77},"strong",{},[78],{"type":45,"value":79},"What it is.",{"type":45,"value":81}," Full-duplex, persistent TCP connection upgraded from HTTP. Both sides can send frames at any time.\n",{"type":39,"tag":75,"props":83,"children":84},{},[85],{"type":45,"value":86},"When to use.",{"type":45,"value":88}," Bidirectional communication with low latency — chat, collaborative editing, multiplayer games, live trading. When the server needs to push AND the client needs to push back frequently.\n",{"type":39,"tag":75,"props":90,"children":91},{},[92],{"type":45,"value":93},"When to avoid.",{"type":45,"value":95}," Unidirectional server-to-client updates (SSE is simpler). Infrequent updates where polling is adequate. Environments where intermediaries (corporate proxies, older load balancers) silently kill long-lived connections.\n",{"type":39,"tag":75,"props":97,"children":98},{},[99],{"type":45,"value":100},"Key decisions.",{"type":45,"value":102}," Binary vs text frames, subprotocol negotiation, per-message compression (permessage-deflate has CPU cost), ping\u002Fpong interval tuning.",{"type":39,"tag":65,"props":104,"children":106},{"id":105},"server-sent-events-sse",[107],{"type":45,"value":108},"Server-Sent Events (SSE)",{"type":39,"tag":48,"props":110,"children":111},{},[112,116,118,125,127,131,133,137],{"type":39,"tag":75,"props":113,"children":114},{},[115],{"type":45,"value":79},{"type":45,"value":117}," Unidirectional server-to-client stream over a standard HTTP response. Built-in reconnection with ",{"type":39,"tag":119,"props":120,"children":122},"code",{"className":121},[],[123],{"type":45,"value":124},"Last-Event-ID",{"type":45,"value":126},". Works through HTTP\u002F2 multiplexing natively.\n",{"type":39,"tag":75,"props":128,"children":129},{},[130],{"type":45,"value":86},{"type":45,"value":132}," Live dashboards, notification feeds, stock tickers — anything where the server pushes and the client only needs HTTP requests for writes. When you want automatic reconnection semantics for free.\n",{"type":39,"tag":75,"props":134,"children":135},{},[136],{"type":45,"value":93},{"type":45,"value":138}," Bidirectional real-time communication. Binary data. When you need more than ~6 concurrent connections per domain in HTTP\u002F1.1 browsers (HTTP\u002F2 eliminates this).",{"type":39,"tag":65,"props":140,"children":142},{"id":141},"long-polling",[143],{"type":45,"value":144},"Long Polling",{"type":39,"tag":48,"props":146,"children":147},{},[148,152,154,158,160,164],{"type":39,"tag":75,"props":149,"children":150},{},[151],{"type":45,"value":79},{"type":45,"value":153}," Client sends a request; server holds it open until there's data or a timeout, then responds. Client immediately sends the next request.\n",{"type":39,"tag":75,"props":155,"children":156},{},[157],{"type":45,"value":86},{"type":45,"value":159}," Fallback when WebSocket and SSE aren't available. Environments with aggressive proxies. When connection frequency is low enough that the overhead is acceptable.\n",{"type":39,"tag":75,"props":161,"children":162},{},[163],{"type":45,"value":93},{"type":45,"value":165}," High-frequency updates (each message requires a full HTTP round-trip). The per-request overhead is substantial compared to persistent connections.",{"type":39,"tag":65,"props":167,"children":169},{"id":168},"webtransport",[170],{"type":45,"value":171},"WebTransport",{"type":39,"tag":48,"props":173,"children":174},{},[175,179,181,185,187,191],{"type":39,"tag":75,"props":176,"children":177},{},[178],{"type":45,"value":79},{"type":45,"value":180}," Multiplexed, bidirectional transport built on HTTP\u002F3 (QUIC). Supports both reliable streams and unreliable datagrams. No head-of-line blocking.\n",{"type":39,"tag":75,"props":182,"children":183},{},[184],{"type":45,"value":86},{"type":45,"value":186}," Latency-sensitive applications where packet loss shouldn't stall unrelated streams — gaming, live media, telemetry. When you need unreliable delivery (datagrams) alongside reliable streams.\n",{"type":39,"tag":75,"props":188,"children":189},{},[190],{"type":45,"value":93},{"type":45,"value":192}," Browser support is still limited. When WebSocket meets your latency requirements. When you don't control the server infrastructure to support HTTP\u002F3.",{"type":39,"tag":65,"props":194,"children":196},{"id":195},"connection-lifecycle",[197],{"type":45,"value":198},"Connection Lifecycle",{"type":39,"tag":48,"props":200,"children":201},{},[202,204,209],{"type":45,"value":203},"Every persistent connection follows the same pattern: ",{"type":39,"tag":75,"props":205,"children":206},{},[207],{"type":45,"value":208},"establish → authenticate → maintain → recover",{"type":45,"value":210},".",{"type":39,"tag":212,"props":213,"children":214},"ul",{},[215,226,236,246],{"type":39,"tag":216,"props":217,"children":218},"li",{},[219,224],{"type":39,"tag":75,"props":220,"children":221},{},[222],{"type":45,"value":223},"Establish.",{"type":45,"value":225}," Negotiate the connection (WebSocket upgrade, SSE stream open). Set initial parameters. The handshake is your one chance to reject bad clients cheaply.",{"type":39,"tag":216,"props":227,"children":228},{},[229,234],{"type":39,"tag":75,"props":230,"children":231},{},[232],{"type":45,"value":233},"Authenticate.",{"type":45,"value":235}," Pass a short-lived token during handshake (query param or first message). Never rely on cookies alone — CSRF is harder to prevent on WebSocket upgrades. Re-validate tokens periodically for long-lived connections.",{"type":39,"tag":216,"props":237,"children":238},{},[239,244],{"type":39,"tag":75,"props":240,"children":241},{},[242],{"type":45,"value":243},"Heartbeat.",{"type":45,"value":245}," Both sides send pings at a regular interval. If a pong is missed, the connection is considered dead. Tune the interval: too fast wastes bandwidth; too slow means minutes of stale \"online\" state. 30 seconds is a common default; 15 seconds for presence-critical systems.",{"type":39,"tag":216,"props":247,"children":248},{},[249,254],{"type":39,"tag":75,"props":250,"children":251},{},[252],{"type":45,"value":253},"Reconnect.",{"type":45,"value":255}," Exponential backoff with jitter. Include the last-seen sequence number so the server can resume without replaying the entire state. Cap the backoff (e.g., 60 seconds) — waiting 10 minutes to reconnect is indistinguishable from being offline.",{"type":39,"tag":65,"props":257,"children":259},{"id":258},"connection-multiplexing",[260],{"type":45,"value":261},"Connection Multiplexing",{"type":39,"tag":48,"props":263,"children":264},{},[265],{"type":45,"value":266},"Multiple logical channels over a single physical connection. Avoids the cost of many TCP handshakes and TLS negotiations. Implement with message framing that includes a channel ID. Watch for: head-of-line blocking in WebSocket (a single TCP stream), priority inversion between channels, complexity of flow control per logical channel.",{"type":39,"tag":58,"props":268,"children":270},{"id":269},"state-synchronization",[271],{"type":45,"value":272},"State Synchronization",{"type":39,"tag":65,"props":274,"children":276},{"id":275},"server-authoritative-state",[277],{"type":45,"value":278},"Server-Authoritative State",{"type":39,"tag":48,"props":280,"children":281},{},[282,286,288,292,294,299],{"type":39,"tag":75,"props":283,"children":284},{},[285],{"type":45,"value":79},{"type":45,"value":287}," The server owns the truth. Clients send intents; the server validates, applies, and broadcasts the result.\n",{"type":39,"tag":75,"props":289,"children":290},{},[291],{"type":45,"value":86},{"type":45,"value":293}," Any system where correctness matters more than perceived latency — financial systems, competitive games, inventory management. When cheating or inconsistency is unacceptable.\n",{"type":39,"tag":75,"props":295,"children":296},{},[297],{"type":45,"value":298},"The cost.",{"type":45,"value":300}," Every action has at least one round-trip of latency before the user sees the result.",{"type":39,"tag":65,"props":302,"children":304},{"id":303},"optimistic-updates-with-server-reconciliation",[305],{"type":45,"value":306},"Optimistic Updates with Server Reconciliation",{"type":39,"tag":48,"props":308,"children":309},{},[310,314,316,320,322,327],{"type":39,"tag":75,"props":311,"children":312},{},[313],{"type":45,"value":79},{"type":45,"value":315}," Client applies changes locally before server confirmation. If the server rejects or modifies the change, the client rolls back or reconciles.\n",{"type":39,"tag":75,"props":317,"children":318},{},[319],{"type":45,"value":86},{"type":45,"value":321}," Collaborative editing, chat message sending, any UI where perceived latency matters. The user sees their action instantly; corrections arrive later.\n",{"type":39,"tag":75,"props":323,"children":324},{},[325],{"type":45,"value":326},"The hard part.",{"type":45,"value":328}," Rolling back user-visible state is jarring. Design for reconciliation (merge the server's response into local state) rather than rollback (undo and redo). The client must maintain a queue of unconfirmed changes and be able to rebase them onto server state.",{"type":39,"tag":65,"props":330,"children":332},{"id":331},"client-prediction",[333],{"type":45,"value":334},"Client Prediction",{"type":39,"tag":48,"props":336,"children":337},{},[338,342,344,348,350,355],{"type":39,"tag":75,"props":339,"children":340},{},[341],{"type":45,"value":79},{"type":45,"value":343}," Client simulates the outcome of actions locally and reconciles when the server's authoritative state arrives. Common in games (client-side prediction with server reconciliation).\n",{"type":39,"tag":75,"props":345,"children":346},{},[347],{"type":45,"value":86},{"type":45,"value":349}," Real-time games, cursor tracking, any interaction where the round-trip latency is perceptible and the outcome is usually predictable.\n",{"type":39,"tag":75,"props":351,"children":352},{},[353],{"type":45,"value":354},"Watch for.",{"type":45,"value":356}," Mispredictions cause visual corrections (\"rubber-banding\"). The prediction logic must match server logic exactly, or divergence accumulates.",{"type":39,"tag":65,"props":358,"children":360},{"id":359},"operational-transformation-ot",[361],{"type":45,"value":362},"Operational Transformation (OT)",{"type":39,"tag":48,"props":364,"children":365},{},[366,370,372,376,378,382],{"type":39,"tag":75,"props":367,"children":368},{},[369],{"type":45,"value":79},{"type":45,"value":371}," Transforms concurrent operations against each other so they can be applied in any order and converge to the same state. Requires a central server to determine operation ordering.\n",{"type":39,"tag":75,"props":373,"children":374},{},[375],{"type":45,"value":86},{"type":45,"value":377}," Text-based collaborative editing (Google Docs uses OT). When you have a reliable central server and need character-level collaboration.\n",{"type":39,"tag":75,"props":379,"children":380},{},[381],{"type":45,"value":93},{"type":45,"value":383}," Decentralized systems (OT requires a single ordering authority). Complex data structures beyond text — OT transform functions become combinatorially complex as operation types grow.",{"type":39,"tag":65,"props":385,"children":387},{"id":386},"crdts-conflict-free-replicated-data-types",[388],{"type":45,"value":389},"CRDTs (Conflict-Free Replicated Data Types)",{"type":39,"tag":48,"props":391,"children":392},{},[393,397,399,403,405,409],{"type":39,"tag":75,"props":394,"children":395},{},[396],{"type":45,"value":79},{"type":45,"value":398}," Data structures where concurrent updates always converge without coordination. No central server needed for correctness — peers can sync directly.\n",{"type":39,"tag":75,"props":400,"children":401},{},[402],{"type":45,"value":86},{"type":45,"value":404}," Offline-capable collaboration, peer-to-peer systems, any system where nodes must work independently and sync later. Text editing (Yjs, Automerge), shared counters, sets, maps.\n",{"type":39,"tag":75,"props":406,"children":407},{},[408],{"type":45,"value":93},{"type":45,"value":410}," When server-authoritative state is simpler and sufficient. CRDTs have memory overhead (they carry metadata for conflict resolution) and some types (text sequences) are significantly more complex to implement correctly than OT. When your data model doesn't map cleanly to available CRDT types.",{"type":39,"tag":65,"props":412,"children":414},{"id":413},"versioning-and-ordering",[415],{"type":45,"value":416},"Versioning and Ordering",{"type":39,"tag":48,"props":418,"children":419},{},[420,425,427,432,434,439,441,446],{"type":39,"tag":75,"props":421,"children":422},{},[423],{"type":45,"value":424},"Sequence numbers.",{"type":45,"value":426}," Simple monotonic counter per stream. Sufficient for single-server systems. Clients can detect gaps and request retransmission.\n",{"type":39,"tag":75,"props":428,"children":429},{},[430],{"type":45,"value":431},"Vector clocks.",{"type":45,"value":433}," Track causal ordering across multiple nodes. Each node maintains a counter per known node. Expensive to compare at scale — the vector grows with the number of participants.\n",{"type":39,"tag":75,"props":435,"children":436},{},[437],{"type":45,"value":438},"Hybrid logical clocks.",{"type":45,"value":440}," Combine physical timestamps with logical counters. More compact than vector clocks, provide causal ordering, and approximate wall-clock time. Good for distributed collaborative systems.\n",{"type":39,"tag":75,"props":442,"children":443},{},[444],{"type":45,"value":445},"Lamport timestamps.",{"type":45,"value":447}," Provide total ordering but not causal ordering. Sufficient when you just need a tiebreaker, not true causality tracking.",{"type":39,"tag":58,"props":449,"children":451},{"id":450},"conflict-resolution",[452],{"type":45,"value":453},"Conflict Resolution",{"type":39,"tag":65,"props":455,"children":457},{"id":456},"last-writer-wins-lww",[458],{"type":45,"value":459},"Last-Writer-Wins (LWW)",{"type":39,"tag":48,"props":461,"children":462},{},[463,467,469,473,475,479],{"type":39,"tag":75,"props":464,"children":465},{},[466],{"type":45,"value":79},{"type":45,"value":468}," Most recent write (by timestamp or version number) wins. Previous concurrent writes are silently discarded.\n",{"type":39,"tag":75,"props":470,"children":471},{},[472],{"type":45,"value":86},{"type":45,"value":474}," User profile updates, settings, any field where the most recent intent is what matters and losing a concurrent write is acceptable.\n",{"type":39,"tag":75,"props":476,"children":477},{},[478],{"type":45,"value":93},{"type":45,"value":480}," Anything additive (counters, lists, collaborative text). Losing a write silently is data loss — LWW just makes it someone else's problem.",{"type":39,"tag":65,"props":482,"children":484},{"id":483},"application-level-merge-strategies",[485],{"type":45,"value":486},"Application-Level Merge Strategies",{"type":39,"tag":48,"props":488,"children":489},{},[490,495,497,502],{"type":39,"tag":75,"props":491,"children":492},{},[493],{"type":45,"value":494},"When conflicts are acceptable.",{"type":45,"value":496}," Most collaborative systems — two users editing different paragraphs, updating different fields. Present both versions and let the user choose, or merge automatically when the changes are non-overlapping.\n",{"type":39,"tag":75,"props":498,"children":499},{},[500],{"type":45,"value":501},"When conflicts are catastrophic.",{"type":45,"value":503}," Financial transactions, inventory reservation, anything where \"both writes happen\" means real-world harm. Use pessimistic locking, serializable transactions, or compare-and-swap operations. Accept the latency cost.",{"type":39,"tag":65,"props":505,"children":507},{"id":506},"crdt-conflict-resolution",[508],{"type":45,"value":509},"CRDT Conflict Resolution",{"type":39,"tag":212,"props":511,"children":512},{},[513,523,533,543],{"type":39,"tag":216,"props":514,"children":515},{},[516,521],{"type":39,"tag":75,"props":517,"children":518},{},[519],{"type":45,"value":520},"G-Counter \u002F PN-Counter.",{"type":45,"value":522}," Grow-only and positive-negative counters. Each node increments its own slot. Sum of all slots is the value. No conflicts possible by construction.",{"type":39,"tag":216,"props":524,"children":525},{},[526,531],{"type":39,"tag":75,"props":527,"children":528},{},[529],{"type":45,"value":530},"G-Set \u002F OR-Set.",{"type":45,"value":532}," Grow-only set (add-only) and observed-remove set (add and remove). OR-Set handles the \"add wins over concurrent remove\" semantic, which is the right default for most applications.",{"type":39,"tag":216,"props":534,"children":535},{},[536,541],{"type":39,"tag":75,"props":537,"children":538},{},[539],{"type":45,"value":540},"LWW-Register.",{"type":45,"value":542}," Last-writer-wins register using timestamps. Simple but lossy — use when losing concurrent writes is tolerable.",{"type":39,"tag":216,"props":544,"children":545},{},[546,551],{"type":39,"tag":75,"props":547,"children":548},{},[549],{"type":45,"value":550},"Text CRDTs (RGA, YATA).",{"type":45,"value":552}," Represent text as a sequence of uniquely identified characters with ordering metadata. Insertions and deletions commute. Libraries like Yjs and Automerge implement these. Memory overhead is real — a 10KB document may use 100KB+ of CRDT metadata.",{"type":39,"tag":58,"props":554,"children":556},{"id":555},"presence-and-awareness",[557],{"type":45,"value":558},"Presence and Awareness",{"type":39,"tag":65,"props":560,"children":562},{"id":561},"onlineoffline-detection",[563],{"type":45,"value":564},"Online\u002FOffline Detection",{"type":39,"tag":48,"props":566,"children":567},{},[568,573,575,580],{"type":39,"tag":75,"props":569,"children":570},{},[571],{"type":45,"value":572},"Heartbeat-based presence.",{"type":45,"value":574}," Client sends periodic heartbeats. Server marks client as offline after missing N consecutive heartbeats. Simple and reliable. Tune the timeout: too aggressive and flaky connections cause presence flickering; too lenient and stale presence lingers for minutes.\n",{"type":39,"tag":75,"props":576,"children":577},{},[578],{"type":45,"value":579},"The fundamental tradeoff.",{"type":45,"value":581}," Fast detection (5-10s timeout) vs stable presence (30-60s timeout). Chat applications typically use 15-30 seconds. Collaborative editors can tolerate 30-60 seconds because the cursor position already conveys activity.",{"type":39,"tag":65,"props":583,"children":585},{"id":584},"cursor-positions-and-selection",[586],{"type":45,"value":587},"Cursor Positions and Selection",{"type":39,"tag":48,"props":589,"children":590},{},[591],{"type":45,"value":592},"Broadcast cursor position on change, throttled to ~10-20 updates per second per user. Include a user identifier and color. Don't broadcast every keystroke position — batch and throttle. For remote cursors, interpolate between received positions to smooth movement.",{"type":39,"tag":65,"props":594,"children":596},{"id":595},"typing-indicators",[597],{"type":45,"value":598},"Typing Indicators",{"type":39,"tag":48,"props":600,"children":601},{},[602],{"type":45,"value":603},"Send a \"started typing\" event. Clear after a timeout (3-5 seconds of inactivity) or an explicit \"stopped typing\" event. Don't send continuous \"is typing\" events — send transitions. Rate-limit outbound typing events to avoid flooding channels with many participants.",{"type":39,"tag":65,"props":605,"children":607},{"id":606},"thundering-herd-on-reconnection",[608],{"type":45,"value":609},"Thundering Herd on Reconnection",{"type":39,"tag":48,"props":611,"children":612},{},[613,615],{"type":45,"value":614},"When a server restarts or a network partition heals, all clients reconnect simultaneously. Every client sends presence updates, subscribes to channels, and requests state catch-up — at the same instant.\n",{"type":39,"tag":75,"props":616,"children":617},{},[618],{"type":45,"value":619},"Mitigations:",{"type":39,"tag":212,"props":621,"children":622},{},[623,633,643,653],{"type":39,"tag":216,"props":624,"children":625},{},[626,631],{"type":39,"tag":75,"props":627,"children":628},{},[629],{"type":45,"value":630},"Jittered reconnect delay.",{"type":45,"value":632}," Clients wait a random interval (0 to N seconds) before reconnecting. Spreads the thundering herd across a time window.",{"type":39,"tag":216,"props":634,"children":635},{},[636,641],{"type":39,"tag":75,"props":637,"children":638},{},[639],{"type":45,"value":640},"Gradual presence broadcast.",{"type":45,"value":642}," After a server restart, don't broadcast all presence updates immediately. Batch and stagger.",{"type":39,"tag":216,"props":644,"children":645},{},[646,651],{"type":39,"tag":75,"props":647,"children":648},{},[649],{"type":45,"value":650},"Connection rate limiting.",{"type":45,"value":652}," Accept connections at a controlled rate. Return \"retry later\" with a backoff hint for excess connections.",{"type":39,"tag":216,"props":654,"children":655},{},[656,661],{"type":39,"tag":75,"props":657,"children":658},{},[659],{"type":45,"value":660},"Stale presence TTL.",{"type":45,"value":662}," Don't immediately mark everyone as offline when a server restarts. Assume recent presence is still valid for a short window while clients reconnect.",{"type":39,"tag":58,"props":664,"children":666},{"id":665},"fan-out-patterns",[667],{"type":45,"value":668},"Fan-Out Patterns",{"type":39,"tag":65,"props":670,"children":672},{"id":671},"per-connection-fan-out",[673],{"type":45,"value":674},"Per-Connection Fan-Out",{"type":39,"tag":48,"props":676,"children":677},{},[678,682,684,688,690,695],{"type":39,"tag":75,"props":679,"children":680},{},[681],{"type":45,"value":79},{"type":45,"value":683}," For each message, iterate over all connected clients and deliver individually.\n",{"type":39,"tag":75,"props":685,"children":686},{},[687],{"type":45,"value":86},{"type":45,"value":689}," Small-scale systems, prototypes, rooms with fewer than ~100 participants.\n",{"type":39,"tag":75,"props":691,"children":692},{},[693],{"type":45,"value":694},"When it breaks.",{"type":45,"value":696}," Delivery time grows linearly with connection count. A room with 10,000 members means 10,000 individual sends per message. CPU and memory on the connection server become the bottleneck.",{"type":39,"tag":65,"props":698,"children":700},{"id":699},"channel-based-routing",[701],{"type":45,"value":702},"Channel-Based Routing",{"type":39,"tag":48,"props":704,"children":705},{},[706,710,712,716,718,723],{"type":39,"tag":75,"props":707,"children":708},{},[709],{"type":45,"value":79},{"type":45,"value":711}," Clients subscribe to named channels (rooms, topics). Messages published to a channel are delivered to all subscribers. The pub\u002Fsub layer handles fan-out.\n",{"type":39,"tag":75,"props":713,"children":714},{},[715],{"type":45,"value":86},{"type":45,"value":717}," Chat rooms, topic-based feeds, any system with natural groupings of interested clients.\n",{"type":39,"tag":75,"props":719,"children":720},{},[721],{"type":45,"value":722},"Implementation.",{"type":45,"value":724}," In-process subscriber lists for single-server. Redis Pub\u002FSub, NATS, or Kafka for multi-server. The pub\u002Fsub layer must deliver to every server that has subscribers for the channel; each server then fans out to its local connections.",{"type":39,"tag":65,"props":726,"children":728},{"id":727},"presence-aware-delivery",[729],{"type":45,"value":730},"Presence-Aware Delivery",{"type":39,"tag":48,"props":732,"children":733},{},[734,738,740,744,746,751],{"type":39,"tag":75,"props":735,"children":736},{},[737],{"type":45,"value":79},{"type":45,"value":739}," Only deliver to clients that are currently online. Queue or drop messages for offline clients based on policy.\n",{"type":39,"tag":75,"props":741,"children":742},{},[743],{"type":45,"value":86},{"type":45,"value":745}," Systems where offline delivery is handled separately (push notifications, email fallback) or where messages are ephemeral (typing indicators, cursor positions).\n",{"type":39,"tag":75,"props":747,"children":748},{},[749],{"type":45,"value":750},"The decision.",{"type":45,"value":752}," What happens to messages for offline users? Options: drop silently (ephemeral data), queue for delivery on reconnect (chat messages), persist and let client pull on reconnect (channel history).",{"type":39,"tag":65,"props":754,"children":756},{"id":755},"the-n-squared-problem",[757],{"type":45,"value":758},"The N-Squared Problem",{"type":39,"tag":48,"props":760,"children":761},{},[762,764],{"type":45,"value":763},"In a room with N participants, each participant's state change (cursor move, typing indicator) must be sent to N-1 others. That's O(N) messages per event, and if all N participants are active, that's O(N²) messages per second. At ~50 participants, this dominates bandwidth.\n",{"type":39,"tag":75,"props":765,"children":766},{},[767],{"type":45,"value":619},{"type":39,"tag":212,"props":769,"children":770},{},[771,781,791,801],{"type":39,"tag":216,"props":772,"children":773},{},[774,779],{"type":39,"tag":75,"props":775,"children":776},{},[777],{"type":45,"value":778},"Throttle per-user broadcasts.",{"type":45,"value":780}," Limit cursor updates to 5-10 per second per user regardless of actual movement frequency.",{"type":39,"tag":216,"props":782,"children":783},{},[784,789],{"type":39,"tag":75,"props":785,"children":786},{},[787],{"type":45,"value":788},"Viewport-aware fan-out.",{"type":45,"value":790}," Only send updates relevant to what each client is viewing. A user viewing page 1 doesn't need cursor positions from page 47.",{"type":39,"tag":216,"props":792,"children":793},{},[794,799],{"type":39,"tag":75,"props":795,"children":796},{},[797],{"type":45,"value":798},"Aggregated updates.",{"type":45,"value":800}," Batch multiple small updates into a single message per delivery interval (e.g., every 50ms). Reduces message count at the cost of slight latency.",{"type":39,"tag":216,"props":802,"children":803},{},[804,809],{"type":39,"tag":75,"props":805,"children":806},{},[807],{"type":45,"value":808},"Tiered presence.",{"type":45,"value":810}," Full presence for focused collaborators; degraded presence (online\u002Foffline only) for observers.",{"type":39,"tag":65,"props":812,"children":814},{"id":813},"scaling-fan-out",[815],{"type":45,"value":816},"Scaling Fan-Out",{"type":39,"tag":48,"props":818,"children":819},{},[820,825],{"type":39,"tag":75,"props":821,"children":822},{},[823],{"type":45,"value":824},"Pub\u002FSub backing.",{"type":45,"value":826}," Use Redis Pub\u002FSub, NATS, or Kafka to distribute messages across connection servers. Each connection server subscribes to channels that its local clients care about. Watch for: Redis Pub\u002FSub is fire-and-forget (no persistence, no replay); Kafka provides persistence but adds latency; NATS JetStream provides a middle ground.",{"type":39,"tag":48,"props":828,"children":829},{},[830,835],{"type":39,"tag":75,"props":831,"children":832},{},[833],{"type":45,"value":834},"Connection affinity.",{"type":45,"value":836}," Route clients in the same channel to the same connection server when possible. Reduces cross-server fan-out. Watch for: uneven distribution when some channels are much larger than others, rebalancing during deploys.",{"type":39,"tag":48,"props":838,"children":839},{},[840,845],{"type":39,"tag":75,"props":841,"children":842},{},[843],{"type":45,"value":844},"Sharded channels.",{"type":45,"value":846}," For very large channels (thousands of subscribers), shard across multiple servers. Each shard handles fan-out for a subset of subscribers. A message published to the channel is forwarded to all shards. Watch for: ordering guarantees across shards, shard rebalancing.",{"type":39,"tag":58,"props":848,"children":850},{"id":849},"reconnection-and-rehydration",[851],{"type":45,"value":852},"Reconnection and Rehydration",{"type":39,"tag":65,"props":854,"children":856},{"id":855},"resumable-connections",[857],{"type":45,"value":858},"Resumable Connections",{"type":39,"tag":48,"props":860,"children":861},{},[862,864,869],{"type":45,"value":863},"Assign each connection a session ID and track the last-delivered sequence number. On reconnect, the client sends its session ID and last-seen sequence number. The server replays missed messages from a buffer.\n",{"type":39,"tag":75,"props":865,"children":866},{},[867],{"type":45,"value":868},"Buffer sizing.",{"type":45,"value":870}," Too small and clients that were offline for a minute get a full resync. Too large and the server holds too much state per connection. A sliding window of 5-10 minutes of messages is typical. Use a ring buffer per channel, not per connection.",{"type":39,"tag":65,"props":872,"children":874},{"id":873},"state-catch-up-after-disconnect",[875],{"type":45,"value":876},"State Catch-Up After Disconnect",{"type":39,"tag":48,"props":878,"children":879},{},[880,885,887,892,894,899],{"type":39,"tag":75,"props":881,"children":882},{},[883],{"type":45,"value":884},"Delta sync.",{"type":45,"value":886}," Client sends its last-known version. Server computes and sends only the changes since that version. Efficient but requires the server to maintain a change log.\n",{"type":39,"tag":75,"props":888,"children":889},{},[890],{"type":45,"value":891},"Full sync.",{"type":45,"value":893}," Client discards local state and downloads everything. Simple but expensive. Acceptable for small state (a chat room's last 50 messages); unacceptable for large state (a collaborative document).\n",{"type":39,"tag":75,"props":895,"children":896},{},[897],{"type":45,"value":898},"Hybrid.",{"type":45,"value":900}," Attempt delta sync. If the client's version is too old (outside the change log window), fall back to full sync. This is the pragmatic approach for most systems.",{"type":39,"tag":65,"props":902,"children":904},{"id":903},"offline-queue",[905],{"type":45,"value":906},"Offline Queue",{"type":39,"tag":48,"props":908,"children":909},{},[910,912,916],{"type":45,"value":911},"Client queues actions performed while disconnected. On reconnect, the queue is replayed against the server.\n",{"type":39,"tag":75,"props":913,"children":914},{},[915],{"type":45,"value":326},{"type":45,"value":917}," Actions in the queue may conflict with changes made by other users while this client was offline. Each queued action must be validated and potentially transformed or rejected by the server. This is where OT and CRDTs earn their complexity budget — they provide principled answers to \"what happens when I replay my offline edits against a state that has moved on.\"",{"type":39,"tag":58,"props":919,"children":921},{"id":920},"scaling-persistent-connections",[922],{"type":45,"value":923},"Scaling Persistent Connections",{"type":39,"tag":65,"props":925,"children":927},{"id":926},"connection-servers-vs-application-servers",[928],{"type":45,"value":929},"Connection Servers vs Application Servers",{"type":39,"tag":48,"props":931,"children":932},{},[933],{"type":45,"value":934},"Separate the concern of holding connections from the concern of processing business logic. Connection servers are I\u002FO-bound (thousands of idle connections, occasional message forwarding). Application servers are CPU-bound (message validation, persistence, business rules). Scaling them independently is the key to cost-efficient real-time systems.",{"type":39,"tag":65,"props":936,"children":938},{"id":937},"sticky-sessions-and-their-downsides",[939],{"type":45,"value":940},"Sticky Sessions and Their Downsides",{"type":39,"tag":48,"props":942,"children":943},{},[944],{"type":45,"value":945},"Persistent connections are inherently sticky — they're bound to the server that accepted the upgrade. This creates problems:",{"type":39,"tag":212,"props":947,"children":948},{},[949,959,969,979],{"type":39,"tag":216,"props":950,"children":951},{},[952,957],{"type":39,"tag":75,"props":953,"children":954},{},[955],{"type":45,"value":956},"Uneven load.",{"type":45,"value":958}," Some servers accumulate more connections over time, especially for popular channels.",{"type":39,"tag":216,"props":960,"children":961},{},[962,967],{"type":39,"tag":75,"props":963,"children":964},{},[965],{"type":45,"value":966},"Deploys require draining.",{"type":45,"value":968}," You can't just kill a server — you must drain connections gracefully, giving clients time to reconnect elsewhere.",{"type":39,"tag":216,"props":970,"children":971},{},[972,977],{"type":39,"tag":75,"props":973,"children":974},{},[975],{"type":45,"value":976},"Server failure is localized.",{"type":45,"value":978}," When a connection server dies, all its clients disconnect simultaneously, creating a localized thundering herd on the remaining servers.",{"type":39,"tag":216,"props":980,"children":981},{},[982,987],{"type":39,"tag":75,"props":983,"children":984},{},[985],{"type":45,"value":986},"No mid-connection rebalancing.",{"type":45,"value":988}," Unlike HTTP requests, you can't redistribute persistent connections without client cooperation.",{"type":39,"tag":65,"props":990,"children":992},{"id":991},"connection-migration-during-deploys",[993],{"type":45,"value":994},"Connection Migration During Deploys",{"type":39,"tag":48,"props":996,"children":997},{},[998,1003,1005,1010,1012,1017],{"type":39,"tag":75,"props":999,"children":1000},{},[1001],{"type":45,"value":1002},"Graceful drain.",{"type":45,"value":1004}," Stop accepting new connections. Send a \"please reconnect\" control message to existing clients with a jittered delay. Wait for connections to close. Shut down.\n",{"type":39,"tag":75,"props":1006,"children":1007},{},[1008],{"type":45,"value":1009},"Blue\u002Fgreen for WebSocket.",{"type":45,"value":1011}," Route new connections to the new deployment. Drain old connections over minutes, not seconds. The overlap period means both old and new servers must handle the same channels.\n",{"type":39,"tag":75,"props":1013,"children":1014},{},[1015],{"type":45,"value":1016},"The deploy budget.",{"type":45,"value":1018}," If you have 100,000 connections and each reconnection takes 100ms of server time, draining all connections simultaneously requires 10,000 seconds of CPU-time. Stagger over 2-5 minutes minimum.",{"type":39,"tag":65,"props":1020,"children":1022},{"id":1021},"backpressure-for-slow-consumers",[1023],{"type":45,"value":1024},"Backpressure for Slow Consumers",{"type":39,"tag":48,"props":1026,"children":1027},{},[1028,1030],{"type":45,"value":1029},"A client on a poor network connection can't receive messages as fast as they're produced. Without backpressure, the server buffers messages per-connection, memory grows, and the server eventually OOMs.\n",{"type":39,"tag":75,"props":1031,"children":1032},{},[1033],{"type":45,"value":1034},"Strategies:",{"type":39,"tag":212,"props":1036,"children":1037},{},[1038,1048,1058],{"type":39,"tag":216,"props":1039,"children":1040},{},[1041,1046],{"type":39,"tag":75,"props":1042,"children":1043},{},[1044],{"type":45,"value":1045},"Per-connection send buffer with a cap.",{"type":45,"value":1047}," If the buffer is full, drop messages (with a \"you missed N messages, resync\" notification) or disconnect the client.",{"type":39,"tag":216,"props":1049,"children":1050},{},[1051,1056],{"type":39,"tag":75,"props":1052,"children":1053},{},[1054],{"type":45,"value":1055},"Priority-based dropping.",{"type":45,"value":1057}," Drop ephemeral messages (cursor positions, typing indicators) before durable messages (chat content). Not all messages are equal.",{"type":39,"tag":216,"props":1059,"children":1060},{},[1061,1066],{"type":39,"tag":75,"props":1062,"children":1063},{},[1064],{"type":45,"value":1065},"Adaptive rate.",{"type":45,"value":1067}," Reduce update frequency for slow consumers. Send aggregated updates instead of individual events.",{"type":39,"tag":65,"props":1069,"children":1071},{"id":1070},"memory-per-connection-at-scale",[1072],{"type":45,"value":1073},"Memory Per Connection at Scale",{"type":39,"tag":48,"props":1075,"children":1076},{},[1077],{"type":45,"value":1078},"Each WebSocket connection costs memory: TCP buffers (~4-8KB), TLS state (~20-50KB), application-level state (subscriptions, session data). At 100,000 connections, that's 2-6GB of overhead before any message buffering. Budget for it. Monitor RSS per connection server. A \"small\" memory leak of 1KB per connection per hour becomes 100MB\u002Fhour at scale.",{"type":39,"tag":58,"props":1080,"children":1082},{"id":1081},"common-failure-modes",[1083],{"type":45,"value":1084},"Common Failure Modes",{"type":39,"tag":212,"props":1086,"children":1087},{},[1088,1098,1108,1118,1128,1138,1148,1158],{"type":39,"tag":216,"props":1089,"children":1090},{},[1091,1096],{"type":39,"tag":75,"props":1092,"children":1093},{},[1094],{"type":45,"value":1095},"Connection storm on deploy.",{"type":45,"value":1097}," Server restart disconnects all clients. They all reconnect simultaneously, overwhelming the new server before it's warmed up. Mitigation: jittered reconnect with exponential backoff, connection rate limiting on the server, pre-warming the new server before draining the old one.",{"type":39,"tag":216,"props":1099,"children":1100},{},[1101,1106],{"type":39,"tag":75,"props":1102,"children":1103},{},[1104],{"type":45,"value":1105},"Slow consumer backpressure.",{"type":45,"value":1107}," A client on a degraded network stops reading. The server buffers outbound messages. Multiply by thousands of slow clients and the server runs out of memory. Mitigation: per-connection buffer limits, drop policy for ephemeral messages, disconnect chronically slow consumers.",{"type":39,"tag":216,"props":1109,"children":1110},{},[1111,1116],{"type":39,"tag":75,"props":1112,"children":1113},{},[1114],{"type":45,"value":1115},"Split-brain in presence.",{"type":45,"value":1117}," Two servers disagree about who is online — one thinks the user connected, the other hasn't received the disconnect. Mitigation: presence TTL with heartbeat renewal, criss-cross presence queries during ambiguity, accept that presence is eventually consistent and design the UI accordingly.",{"type":39,"tag":216,"props":1119,"children":1120},{},[1121,1126],{"type":39,"tag":75,"props":1122,"children":1123},{},[1124],{"type":45,"value":1125},"Message ordering across shards.",{"type":45,"value":1127}," Messages published to different shards of a channel arrive at clients in different orders. Mitigation: include a causal ordering field (sequence number or timestamp) and let the client reorder. Accept that total ordering across shards is expensive and usually unnecessary.",{"type":39,"tag":216,"props":1129,"children":1130},{},[1131,1136],{"type":39,"tag":75,"props":1132,"children":1133},{},[1134],{"type":45,"value":1135},"Thundering herd on network partition heal.",{"type":45,"value":1137}," A network partition between data centers heals. Thousands of connections that were in \"reconnecting\" state all succeed at once. Both data centers flood each other with state sync. Mitigation: jittered reconnection, rate-limited sync, partition-aware message deduplication.",{"type":39,"tag":216,"props":1139,"children":1140},{},[1141,1146],{"type":39,"tag":75,"props":1142,"children":1143},{},[1144],{"type":45,"value":1145},"Memory leaks from abandoned connections.",{"type":45,"value":1147}," Client process crashes without sending a close frame. The server holds the connection open until the next heartbeat timeout. If heartbeats are infrequent or the cleanup path has bugs, connections accumulate. Mitigation: aggressive heartbeat timeouts (30s), periodic connection audits, process-level memory monitoring with alerts.",{"type":39,"tag":216,"props":1149,"children":1150},{},[1151,1156],{"type":39,"tag":75,"props":1152,"children":1153},{},[1154],{"type":45,"value":1155},"Fan-out amplification.",{"type":45,"value":1157}," A single message to a large channel generates thousands of outbound messages. If the channel has 50,000 subscribers across 100 servers, one inbound message becomes 50,000 outbound messages. Mitigation: sharded fan-out, hierarchical pub\u002Fsub (edge servers aggregate), rate limiting per-channel publish.",{"type":39,"tag":216,"props":1159,"children":1160},{},[1161,1166],{"type":39,"tag":75,"props":1162,"children":1163},{},[1164],{"type":45,"value":1165},"Stale state after long disconnect.",{"type":45,"value":1167}," Client reconnects after being offline for hours. The delta sync window has expired. The client has a deeply stale local state and applies offline changes against it. Mitigation: version-aware reconnection that detects when delta sync is impossible and forces full resync, discard offline queue when the gap is too large.",{"type":39,"tag":58,"props":1169,"children":1171},{"id":1170},"anti-patterns",[1172],{"type":45,"value":1173},"Anti-Patterns",{"type":39,"tag":212,"props":1175,"children":1176},{},[1177,1187,1197,1207,1217,1227,1237,1247,1257],{"type":39,"tag":216,"props":1178,"children":1179},{},[1180,1185],{"type":39,"tag":75,"props":1181,"children":1182},{},[1183],{"type":45,"value":1184},"Polling in a WebSocket.",{"type":45,"value":1186}," Opening a WebSocket and then having the client poll for updates on it every N seconds. You have a persistent connection — use server push. If you're polling, you didn't need WebSocket.",{"type":39,"tag":216,"props":1188,"children":1189},{},[1190,1195],{"type":39,"tag":75,"props":1191,"children":1192},{},[1193],{"type":45,"value":1194},"Unbounded per-connection buffers.",{"type":45,"value":1196}," Buffering all messages for every slow client without limits. One degraded mobile client on a busy channel can consume gigabytes of server memory. Always cap buffers and have a drop or disconnect policy.",{"type":39,"tag":216,"props":1198,"children":1199},{},[1200,1205],{"type":39,"tag":75,"props":1201,"children":1202},{},[1203],{"type":45,"value":1204},"Presence as ground truth.",{"type":45,"value":1206}," Treating presence state as strongly consistent. Presence is inherently best-effort — network delays, heartbeat windows, and race conditions mean presence will occasionally be wrong. Design the application to tolerate showing a user as online for 30 seconds after they left. Never make authorization decisions based on presence.",{"type":39,"tag":216,"props":1208,"children":1209},{},[1210,1215],{"type":39,"tag":75,"props":1211,"children":1212},{},[1213],{"type":45,"value":1214},"Synchronous persistence in the message path.",{"type":45,"value":1216}," Writing every message to a database before delivering to subscribers. This puts database latency in the critical path of every real-time message. Deliver first, persist asynchronously. Accept the small window of potential message loss or use a write-ahead log.",{"type":39,"tag":216,"props":1218,"children":1219},{},[1220,1225],{"type":39,"tag":75,"props":1221,"children":1222},{},[1223],{"type":45,"value":1224},"Global ordering for everything.",{"type":45,"value":1226}," Requiring total ordering across all messages in the system. Total ordering requires a single sequencer — a bottleneck by design. Most applications only need ordering within a channel or conversation. Identify where ordering actually matters and scope it narrowly.",{"type":39,"tag":216,"props":1228,"children":1229},{},[1230,1235],{"type":39,"tag":75,"props":1231,"children":1232},{},[1233],{"type":45,"value":1234},"Reconnecting without backoff.",{"type":45,"value":1236}," Client immediately retries on disconnect, in a tight loop. Multiplied across thousands of clients hitting a struggling server, this turns a transient failure into a permanent one. Always use exponential backoff with jitter. Always.",{"type":39,"tag":216,"props":1238,"children":1239},{},[1240,1245],{"type":39,"tag":75,"props":1241,"children":1242},{},[1243],{"type":45,"value":1244},"Treating WebSocket connections as cheap.",{"type":45,"value":1246}," Opening a connection per feature (one for chat, one for notifications, one for presence). Each connection has TLS, TCP, and memory overhead. Multiplex logical channels over a single connection. One connection per client, not per feature.",{"type":39,"tag":216,"props":1248,"children":1249},{},[1250,1255],{"type":39,"tag":75,"props":1251,"children":1252},{},[1253],{"type":45,"value":1254},"CRDTs for everything.",{"type":45,"value":1256}," Reaching for CRDTs because they sound elegant when server-authoritative state with simple last-writer-wins would suffice. CRDTs have real memory and complexity costs. Use them when you need offline-capable collaboration or decentralized sync. Use simpler models when you don't.",{"type":39,"tag":216,"props":1258,"children":1259},{},[1260,1265],{"type":39,"tag":75,"props":1261,"children":1262},{},[1263],{"type":45,"value":1264},"Ignoring the deploy problem.",{"type":45,"value":1266}," Designing the real-time system without a plan for zero-downtime deploys. Persistent connections make deploys fundamentally harder than stateless HTTP services. If you haven't designed graceful drain and reconnection, your first deploy under load will teach you why you should have.",{"items":1268,"total":1349},[1269,1281,1296,1306,1318,1333,1339],{"slug":1270,"name":1270,"fn":1271,"description":1272,"org":1273,"tags":1274,"stars":22,"repoUrl":23,"updatedAt":1280},"design-philosophy-domain-driven","model complex systems with domain-driven design","Domain-Driven Design as a lens for system architecture — bounded contexts, aggregates, ubiquitous language, context mapping, domain events, and strategic vs tactical patterns. Use when modeling complex business domains, defining service boundaries, or evaluating whether a system's structure reflects its domain.",{"slug":8,"name":9,"logoUrl":10,"githubOrg":8},[1275,1276,1279],{"name":13,"slug":14,"type":15},{"name":1277,"slug":1278,"type":15},"Data Modeling","data-modeling",{"name":17,"slug":18,"type":15},"2026-07-07T06:53:28.678913",{"slug":1282,"name":1282,"fn":1283,"description":1284,"org":1285,"tags":1286,"stars":22,"repoUrl":23,"updatedAt":1295},"design-philosophy-linux","apply Unix and Linux design philosophy","The Unix\u002FLinux design philosophy as a lens for system design — mechanism vs policy, composability, small tools, text streams, convention over configuration, and the principle of least surprise. Use when evaluating designs for composability, simplicity, or separation of concerns.",{"slug":8,"name":9,"logoUrl":10,"githubOrg":8},[1287,1288,1291,1294],{"name":13,"slug":14,"type":15},{"name":1289,"slug":1290,"type":15},"Engineering","engineering",{"name":1292,"slug":1293,"type":15},"Linux","linux",{"name":17,"slug":18,"type":15},"2026-05-13T06:14:50.770309",{"slug":1297,"name":1297,"fn":1298,"description":1299,"org":1300,"tags":1301,"stars":22,"repoUrl":23,"updatedAt":1305},"system-type-distributed","apply distributed systems design patterns","Foundational patterns for distributed systems — consensus, consistency models, replication, partitioning, clock synchronization, distributed transactions, and failure modes. Use when designing or evaluating any system that spans multiple nodes, processes, or failure domains.",{"slug":8,"name":9,"logoUrl":10,"githubOrg":8},[1302,1303,1304],{"name":13,"slug":14,"type":15},{"name":1289,"slug":1290,"type":15},{"name":17,"slug":18,"type":15},"2026-05-13T06:14:49.388552",{"slug":1307,"name":1307,"fn":1308,"description":1309,"org":1310,"tags":1311,"stars":22,"repoUrl":23,"updatedAt":1317},"system-type-event-driven","design event-driven and message-based systems","Domain patterns for event-driven and message-based systems — pub\u002Fsub, event sourcing, CQRS, sagas, delivery guarantees, schema evolution, and failure modes. Use when designing or evaluating systems built around events, messages, or asynchronous workflows.",{"slug":8,"name":9,"logoUrl":10,"githubOrg":8},[1312,1313,1316],{"name":13,"slug":14,"type":15},{"name":1314,"slug":1315,"type":15},"Messaging","messaging",{"name":17,"slug":18,"type":15},"2026-07-07T06:53:27.291427",{"slug":1319,"name":1319,"fn":1320,"description":1321,"org":1322,"tags":1323,"stars":22,"repoUrl":23,"updatedAt":1332},"system-type-ml-serving","design ML serving and training systems","Domain patterns for ML\u002FAI serving and training systems — model serving, feature stores, training pipelines, experiment tracking, A\u002FB testing, GPU scheduling, and failure modes. Use when designing or evaluating machine learning infrastructure, model serving platforms, or AI-powered product features.",{"slug":8,"name":9,"logoUrl":10,"githubOrg":8},[1324,1327,1330,1331],{"name":1325,"slug":1326,"type":15},"AI Infrastructure","ai-infrastructure",{"name":1328,"slug":1329,"type":15},"Deep Learning","deep-learning",{"name":1289,"slug":1290,"type":15},{"name":17,"slug":18,"type":15},"2026-07-03T16:31:59.997224",{"slug":4,"name":4,"fn":5,"description":6,"org":1334,"tags":1335,"stars":22,"repoUrl":23,"updatedAt":24},{"slug":8,"name":9,"logoUrl":10,"githubOrg":8},[1336,1337,1338],{"name":13,"slug":14,"type":15},{"name":20,"slug":21,"type":15},{"name":17,"slug":18,"type":15},{"slug":1340,"name":1340,"fn":1341,"description":1342,"org":1343,"tags":1344,"stars":22,"repoUrl":23,"updatedAt":1348},"systems-design-review-methodology","perform systems design reviews","Use when the \u002Fsystems-design-review mode is active. 7-step design review methodology -- understand the design, classify the system, evaluate against codebase, adversarial analysis, tradeoff validation, synthesis, and action items. Governs conversation flow, delegation patterns, and user validation checkpoints.",{"slug":8,"name":9,"logoUrl":10,"githubOrg":8},[1345,1346,1347],{"name":13,"slug":14,"type":15},{"name":1289,"slug":1290,"type":15},{"name":17,"slug":18,"type":15},"2026-07-03T16:31:58.725837",7,{"items":1351,"total":1542},[1352,1372,1393,1414,1427,1444,1455,1468,1483,1498,1517,1530],{"slug":1353,"name":1353,"fn":1354,"description":1355,"org":1356,"tags":1357,"stars":1369,"repoUrl":1370,"updatedAt":1371},"rushstack-best-practices","manage Rush monorepos with best practices","Provides best practices and guidance for working with Rush monorepos. Use when the user is working in a Rush-based repository, asks about Rush commands (install, update, build, rebuild), needs help with project selection, dependency management, build caching, subspace configuration, or troubleshooting Rush-specific issues.",{"slug":8,"name":9,"logoUrl":10,"githubOrg":8},[1358,1359,1362,1363,1366],{"name":1289,"slug":1290,"type":15},{"name":1360,"slug":1361,"type":15},"Local Development","local-development",{"name":9,"slug":8,"type":15},{"name":1364,"slug":1365,"type":15},"Project Management","project-management",{"name":1367,"slug":1368,"type":15},"Rush","rush",6484,"https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Frushstack","2026-04-06T18:34:44.965032",{"slug":1373,"name":1373,"fn":1374,"description":1375,"org":1376,"tags":1377,"stars":1390,"repoUrl":1391,"updatedAt":1392},"azure-ai-agents-persistent-dotnet","build AI agents with Azure .NET SDK","Azure AI Agents Persistent SDK for .NET. Low-level SDK for creating and managing AI agents with threads, messages, runs, and tools. Use for agent CRUD, conversation threads, streaming responses, function calling, file search, and code interpreter. Triggers: \"PersistentAgentsClient\", \"persistent agents\", \"agent threads\", \"agent runs\", \"streaming agents\", \"function calling agents .NET\".\n",{"slug":8,"name":9,"logoUrl":10,"githubOrg":8},[1378,1381,1384,1387],{"name":1379,"slug":1380,"type":15},".NET","net",{"name":1382,"slug":1383,"type":15},"Agents","agents",{"name":1385,"slug":1386,"type":15},"Azure","azure",{"name":1388,"slug":1389,"type":15},"LLM","llm",2804,"https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fskills","2026-07-03T16:32:10.297433",{"slug":1394,"name":1394,"fn":1395,"description":1396,"org":1397,"tags":1398,"stars":1390,"repoUrl":1391,"updatedAt":1413},"azure-ai-anomalydetector-java","build anomaly detection applications with Java","Build anomaly detection applications with Azure AI Anomaly Detector SDK for Java. Use when implementing univariate\u002Fmultivariate anomaly detection, time-series analysis, or AI-powered monitoring.",{"slug":8,"name":9,"logoUrl":10,"githubOrg":8},[1399,1402,1403,1406,1409,1410],{"name":1400,"slug":1401,"type":15},"Analytics","analytics",{"name":1385,"slug":1386,"type":15},{"name":1404,"slug":1405,"type":15},"Data Analysis","data-analysis",{"name":1407,"slug":1408,"type":15},"Java","java",{"name":9,"slug":8,"type":15},{"name":1411,"slug":1412,"type":15},"Monitoring","monitoring","2026-05-13T06:14:16.261754",{"slug":1415,"name":1415,"fn":1416,"description":1417,"org":1418,"tags":1419,"stars":1390,"repoUrl":1391,"updatedAt":1426},"azure-ai-contentsafety-java","build content moderation applications with Azure AI","Build content moderation applications with Azure AI Content Safety SDK for Java. Use when implementing text\u002Fimage analysis, blocklist management, or harm detection for hate, violence, sexual content, and self-harm.",{"slug":8,"name":9,"logoUrl":10,"githubOrg":8},[1420,1421,1422,1423],{"name":1325,"slug":1326,"type":15},{"name":1385,"slug":1386,"type":15},{"name":1407,"slug":1408,"type":15},{"name":1424,"slug":1425,"type":15},"Security","security","2026-07-07T06:53:31.293235",{"slug":1428,"name":1428,"fn":1429,"description":1430,"org":1431,"tags":1432,"stars":1390,"repoUrl":1391,"updatedAt":1443},"azure-ai-contentsafety-py","detect harmful content with Azure AI Content Safety","Azure AI Content Safety SDK for Python. Use for detecting harmful content in text and images with multi-severity classification.\nTriggers: \"azure-ai-contentsafety\", \"ContentSafetyClient\", \"content moderation\", \"harmful content\", \"text analysis\", \"image analysis\".\n",{"slug":8,"name":9,"logoUrl":10,"githubOrg":8},[1433,1434,1437,1438,1439,1442],{"name":1385,"slug":1386,"type":15},{"name":1435,"slug":1436,"type":15},"Compliance","compliance",{"name":1388,"slug":1389,"type":15},{"name":9,"slug":8,"type":15},{"name":1440,"slug":1441,"type":15},"Python","python",{"name":1424,"slug":1425,"type":15},"2026-07-18T05:14:23.017504",{"slug":1445,"name":1445,"fn":1446,"description":1447,"org":1448,"tags":1449,"stars":1390,"repoUrl":1391,"updatedAt":1454},"azure-ai-language-conversations-py","implement conversational language understanding with Python","Implement Conversational Language Understanding (CLU) using the azure-ai-language-conversations Python SDK. Use when working with ConversationAnalysisClient to analyze conversation intent and entities, building NLP features, or integrating language understanding into applications.",{"slug":8,"name":9,"logoUrl":10,"githubOrg":8},[1450,1451,1452,1453],{"name":1400,"slug":1401,"type":15},{"name":1385,"slug":1386,"type":15},{"name":1388,"slug":1389,"type":15},{"name":1440,"slug":1441,"type":15},"2026-07-31T05:54:29.068751",{"slug":1456,"name":1456,"fn":1457,"description":1458,"org":1459,"tags":1460,"stars":1390,"repoUrl":1391,"updatedAt":1467},"azure-ai-translation-text-py","translate text using Azure AI services","Azure AI Text Translation SDK for real-time text translation, transliteration, language detection, and dictionary lookup. Use for translating text content in applications.\nTriggers: \"text translation\", \"translator\", \"translate text\", \"transliterate\", \"TextTranslationClient\".\n",{"slug":8,"name":9,"logoUrl":10,"githubOrg":8},[1461,1464,1465,1466],{"name":1462,"slug":1463,"type":15},"API Development","api-development",{"name":1385,"slug":1386,"type":15},{"name":9,"slug":8,"type":15},{"name":1440,"slug":1441,"type":15},"2026-07-18T05:14:16.988376",{"slug":1469,"name":1469,"fn":1470,"description":1471,"org":1472,"tags":1473,"stars":1390,"repoUrl":1391,"updatedAt":1482},"azure-ai-vision-imageanalysis-py","analyze images with Azure AI Vision","Azure AI Vision Image Analysis SDK for captions, tags, objects, OCR, people detection, and smart cropping. Use for computer vision and image understanding tasks.\nTriggers: \"image analysis\", \"computer vision\", \"OCR\", \"object detection\", \"ImageAnalysisClient\", \"image caption\".\n",{"slug":8,"name":9,"logoUrl":10,"githubOrg":8},[1474,1475,1478,1481],{"name":1385,"slug":1386,"type":15},{"name":1476,"slug":1477,"type":15},"Computer Vision","computer-vision",{"name":1479,"slug":1480,"type":15},"Images","images",{"name":1440,"slug":1441,"type":15},"2026-07-18T05:14:18.007737",{"slug":1484,"name":1484,"fn":1485,"description":1486,"org":1487,"tags":1488,"stars":1390,"repoUrl":1391,"updatedAt":1497},"azure-appconfiguration-java","manage configuration with Azure App Configuration","Azure App Configuration SDK for Java. Centralized application configuration management with key-value settings, feature flags, and snapshots.\nTriggers: \"ConfigurationClient java\", \"app configuration java\", \"feature flag java\", \"configuration setting java\", \"azure config java\".\n",{"slug":8,"name":9,"logoUrl":10,"githubOrg":8},[1489,1490,1493,1496],{"name":1385,"slug":1386,"type":15},{"name":1491,"slug":1492,"type":15},"Configuration","configuration",{"name":1494,"slug":1495,"type":15},"Feature Flags","feature-flags",{"name":1407,"slug":1408,"type":15},"2026-07-03T16:32:01.278468",{"slug":1499,"name":1499,"fn":1500,"description":1501,"org":1502,"tags":1503,"stars":1390,"repoUrl":1391,"updatedAt":1516},"azure-cosmos-rust","build applications with Azure Cosmos DB","Azure Cosmos DB library for Rust (NoSQL API). Document CRUD, containers, and globally distributed data.\nTriggers: \"cosmos db rust\", \"CosmosClient rust\", \"document crud rust\", \"NoSQL rust\", \"partition key rust\".\n",{"slug":8,"name":9,"logoUrl":10,"githubOrg":8},[1504,1507,1510,1513],{"name":1505,"slug":1506,"type":15},"Cosmos DB","cosmos-db",{"name":1508,"slug":1509,"type":15},"Database","database",{"name":1511,"slug":1512,"type":15},"NoSQL","nosql",{"name":1514,"slug":1515,"type":15},"Rust","rust","2026-07-31T05:54:27.021432",{"slug":1518,"name":1518,"fn":1500,"description":1519,"org":1520,"tags":1521,"stars":1390,"repoUrl":1391,"updatedAt":1529},"azure-cosmos-ts","Azure Cosmos DB JavaScript\u002FTypeScript SDK (@azure\u002Fcosmos) for data plane operations. Use for CRUD operations on documents, queries, bulk operations, and container management. Triggers: \"Cosmos DB\", \"@azure\u002Fcosmos\", \"CosmosClient\", \"document CRUD\", \"NoSQL queries\", \"bulk operations\", \"partition key\", \"container.items\".\n",{"slug":8,"name":9,"logoUrl":10,"githubOrg":8},[1522,1523,1524,1525,1526],{"name":1505,"slug":1506,"type":15},{"name":1508,"slug":1509,"type":15},{"name":9,"slug":8,"type":15},{"name":1511,"slug":1512,"type":15},{"name":1527,"slug":1528,"type":15},"TypeScript","typescript","2026-07-03T16:31:19.368382",{"slug":1531,"name":1531,"fn":1532,"description":1533,"org":1534,"tags":1535,"stars":1390,"repoUrl":1391,"updatedAt":1541},"azure-data-tables-java","build table storage applications with Java","Build table storage applications with Azure Tables SDK for Java. Use when working with Azure Table Storage or Cosmos DB Table API for NoSQL key-value data, schemaless storage, or structured data at scale.",{"slug":8,"name":9,"logoUrl":10,"githubOrg":8},[1536,1537,1538,1539,1540],{"name":1385,"slug":1386,"type":15},{"name":1505,"slug":1506,"type":15},{"name":1508,"slug":1509,"type":15},{"name":1407,"slug":1408,"type":15},{"name":1511,"slug":1512,"type":15},"2026-05-13T06:14:17.582229",267]