Backpressure, Retries, and Acknowledgements

These mechanisms solve different failure windows. Treating them as synonyms is the fastest way to misunderstand Vector.

Backpressure limits admission

WhenFull::Block waits for buffer capacity. That wait propagates through fanout, transforms, pumps, and eventually the source. A pull-based source can stop polling; a socket source may stop reading; an upstream client may wait.

DropNewest preserves upstream responsiveness by sacrificing new data. Overflow tries a later buffer stage. These are product policies, not merely performance settings.

A memory buffer absorbs bursts, not crashes

A bounded memory buffer smooths differences between producer and consumer timing. It cannot survive process loss. A disk buffer changes the durability boundary by persisting data, but introduces storage capacity, corruption, and flush semantics that operators must monitor.

Durability answers “will queued data survive?” Backpressure answers “what happens when the queue is full?”

Batching trades latency for efficiency

Network sinks accumulate events until a size, count, or time condition is met. Encoding one batch amortizes headers, compression, and round trips. It also means one service request may own finalizers from many source events.

A bounded request-builder concurrency limit prevents CPU-heavy encoding and compression from turning backlog into unlimited spawned work.

Retry classifies outcomes

RetryLogic examines a response or error and returns Successful, Retry, RetryPartial, or DontRetry. A Fibonacci backoff policy and configured limits control when another attempt is made. The request remains unresolved while the Tower retry layer owns it.

Source: retries.rs:17

Only after retry policy produces a terminal result does the outer driver update event finalizers. This ordering prevents a temporary 503 from being reported to the source as final rejection before retries are exhausted.

Acknowledgement aggregates branches

A source creates a BatchNotifier and attaches cloned handles to events. When fanout duplicates an event, the finalizer’s Arc gains owners. Each sink sets a status and drops its owners after terminal delivery. The notifier’s one-shot resolves only after all relevant owners are gone.

Source: finalization.rs:257

Transforms must preserve, split, merge, or deliberately finalize this metadata when they change event cardinality. That is why finalization capabilities occur in core event and buffer trait bounds.

At-least-once permits duplicates

If a destination accepts a request but its response is lost, retry can deliver the same events again. Without a destination-supported idempotency key or transaction protocol, the sender cannot distinguish “not delivered” from “delivered but response lost.” Vector therefore does not claim exactly-once delivery from generic retry alone.

Shutdown drains from the source side

RunningTopology::stop signals sources first. Transforms and sinks finish when their upstream inputs close, allowing buffered events to move toward delivery. It tracks all task handles, reports lagging components, and can force shutdown after a configured deadline.

Source: running.rs:137