Backpressure

A fault-tolerance design pattern that prevents an application from repeatedly calling a failing service. It functions like an electrical circuit breaker:

• Closed State: Requests flow normally.
• Open State: Requests fail immediately without calling the service, allowing it time to recover.
• Half-Open State: A limited number of test requests are allowed to probe if the service is healthy again. This pattern stops cascading failures and is a proactive companion to reactive backpressure.

A fault isolation design that partitions system resources (e.g., thread pools, connections, memory) into isolated groups (bulkheads). If one component fails and exhausts its allocated resources, the failure is contained, preventing a total system collapse. Key implementations include:

• Thread pool isolation for different service clients.
• Database connection pool separation for critical vs. non-critical functions.
• Microservice instance segregation. This pattern complements backpressure by ensuring a slow or failing consumer doesn't monopolize all system capacity.

A holding queue for messages or events that cannot be delivered or processed successfully after multiple retry attempts. It acts as a safety net in streaming and messaging systems:

• Isolates poison pills: Messages causing repeated processing failures are moved to the DLQ for offline analysis.
• Preserves data: Prevents data loss from permanent failures.
• Enables manual remediation: Engineers can inspect, fix, and replay messages. While backpressure handles transient slowdowns, a DLQ handles messages that are definitively unprocessable, ensuring they don't block the main processing queue.

A retry algorithm used by clients when a request to a service fails. Instead of retrying immediately or at fixed intervals, the wait time between retries increases exponentially (e.g., 1s, 2s, 4s, 8s). It is often combined with jitter (randomization) to prevent synchronized retry storms.

• Use Case: A client receiving backpressure signals (e.g., HTTP 429 Too Many Requests) should use exponential backoff before retrying.
• Prevents Thundering Herd: Avoids overwhelming a recovering service with simultaneous retries from many clients. This is a client-side strategy that responds to server-side backpressure signals.

A design philosophy where a system maintains limited, core functionality when non-essential components fail, rather than suffering a complete outage. This is a higher-level outcome enabled by patterns like backpressure and circuit breakers. Examples include:

• A video streaming service reducing resolution when bandwidth is constrained.
• An e-commerce site disabling product recommendations but keeping the shopping cart and checkout functional during a database failure.
• An API returning cached data or a simplified response when a downstream service is slow. Backpressure is a mechanism that enables graceful degradation by signaling components to reduce their load.

A diagnostic check used by an orchestrator (like Kubernetes) to determine the operational status of a service instance. There are two primary types:

• Liveness Probe: Determines if the container is running. Failure results in a restart.
• Readiness Probe: Determines if the container is ready to accept traffic. Failure removes the pod from the service load balancer. Health probes are a prerequisite for effective backpressure. A service overwhelmed by traffic should fail its readiness probe, signaling the orchestrator to stop sending new requests—a form of infrastructure-level backpressure.