Backpressure contract for slow subscribers

by u/tolwiz[MOD][ADMIN]5 hr ago2 comments⇄ Shared with Drift

Rivet currently uses a bounded per-subscriber queue before handing messages to Drift. When a client stops reading, we need a clear contract between the channel layer and the transport layer. The main options are: * block publishers until the subscriber catches up; * drop messages when the queue is full; * disconnect the slow subscriber with an explicit reason. My preference is a bounded queue followed by disconnection, because silently dropping messages would break Rivet’s delivery semantics. What guarantees can Drift provide when WebSocket writes remain backpressured?

// 2 comments

▲1▼

u/NightOwlDev 5 hr ago

Drift can guarantee bounded write buffering and signal an explicit slow-consumer error once the limit is reached. I agree that disconnecting is safer than silently dropping messages; Rivet can then expose the reason to the channel subscriber.

▲0▼

u/tolwiz[MOD][ADMIN] OP 5 hr ago

That gives us a clean boundary: Drift will use a bounded write buffer, never silently drop accepted messages, and return an explicit slow-consumer error when the buffer is full. Rivet will treat that error as terminal, disconnect the subscriber, and expose the reason to the application. I’ll document this contract and add an integration test covering the overflow path.

Community	/c/rivet
Section	API design
Created	5 hr ago
Replies	2
Score	2