Resilience Patterns · Core Resilience Patterns

Backpressure

Propagate 'slow down' signals instead of buffering until you crash.

Backpressure means a slow consumer signals producers to slow down, rather than letting buffers grow without bound. Mechanisms: bounded queues that block or reject, TCP flow control, reactive streams (request(n)), HTTP 429/503 with Retry-After, Kafka consumer lag driving producer throttling or autoscaling. Every queue in a system should be bounded with a defined overflow policy.

Overflow policies for bounded queues

Overflow policy Behavior Use when
Block producer Producer waits In-process pipelines
Reject (429/503) Caller retries later Request/response APIs
Drop oldest / newest Lose data Metrics, telemetry
Spill to durable queue Absorb bursts Business events
Scale consumers Increase capacity Elastic workloads
import { pipeline } from "node:stream/promises";
// pipeline() respects backpressure: the source pauses when the destination's buffer is full
await pipeline(dbCursorStream, transformToCsv, httpResponse);

Common pitfalls

  • Unbounded in-memory queues (OOM under load).
  • Ignoring consumer lag until disks fill.
  • Dropping business data silently.

Key points

  • Bound every queue
  • Define overflow policy
  • Signal producers to slow down

Further reading: Reactive Streams

Practice questions

What happens without backpressure when a consumer is slower than its producer?

Answer

Buffers grow without bound until memory or disk is exhausted, causing crashes and data loss, often far from the original bottleneck.

Which overflow policy suits telemetry vs payment events?

Answer

Telemetry can drop (oldest/newest) under pressure; payment events must be durably queued and processed later.

Open in the app to mark lessons complete, take notes and track your progress.