# backpressure

Published articles for backpressure.

This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles.

## TokenScale: Timely and Accurate Autoscaling for Disaggregated LLM Serving with Token Velocity

DevFeed: [TokenScale: Timely and Accurate Autoscaling for Disaggregated LLM Serving with Token Velocity](<https://devfeed.tech/articles/tokenscale-timely-and-accurate-autoscaling-for-disaggregated-llm-serving-with-token-velocity-119083.md>)

Original publisher: [Read original article](<https://arxiv.org/abs/2512.03416>)

Author: Ruiqi Lai, Hongrui Liu, Chengzhi Lu, Zonghao Liu, Siyu Cao, Siyang Shao, Yixin Zhang, Luo Mai, Dmitrii Ustiugov

Published: 2026-11-05T05:00:00Z

Content type: article

Language: en

Sources: [arXiv: Distributed Computing](<https://devfeed.tech/sources/arxiv-distributed-computing.md>)

Topics: [LLM optimization](<https://devfeed.tech/topics/llm-optimization.md>), [performance-engineering](<https://devfeed.tech/topics/performance-engineering.md>), [Large Language Model](<https://devfeed.tech/topics/llm.md>), [Latency](<https://devfeed.tech/topics/latency.md>)

Tags: [autoscaling](<https://devfeed.tech/tags/autoscaling.md>), [backpressure](<https://devfeed.tech/tags/backpressure.md>), [costs](<https://devfeed.tech/tags/costs.md>), [cs-dc](<https://devfeed.tech/tags/cs-dc.md>), [disaggregation](<https://devfeed.tech/tags/disaggregation.md>), [evaluation](<https://devfeed.tech/tags/evaluation.md>), [gpu](<https://devfeed.tech/tags/gpu.md>), [latency](<https://devfeed.tech/tags/latency.md>), [llm](<https://devfeed.tech/tags/llm.md>), [llm-serving](<https://devfeed.tech/tags/llm-serving.md>), [performance](<https://devfeed.tech/tags/performance.md>), [prefill](<https://devfeed.tech/tags/prefill.md>), [proactive](<https://devfeed.tech/tags/proactive.md>), [production](<https://devfeed.tech/tags/production.md>), [resource-utilization](<https://devfeed.tech/tags/resource-utilization.md>), [system-design](<https://devfeed.tech/tags/system-design.md>), [token](<https://devfeed.tech/tags/token.md>)

### AI overview

TokenScale aims to reduce SLO violations and over-provisioning in disaggregated LLM serving by pairing a leading indicator with a burst-response mechanism. Its Token Velocity metric measures work rate across prefill, network, and decode stages to signal backpressure early and support proactive scaling. Convertible Decoders let decoder GPUs take on prefill work during traffic spikes, avoiding the initialization delay of new prefillers. In evaluation on a GPU cluster using production traces, TokenScale raised SLO attainment from 50-88% to 80-96% and reduced costs by 4-14% compared with DistServe, BlitzScale, and AIBrix. The supplied text is an abstract and does not detail evaluation conditions or the metric's implementation.

### Source excerpt

arXiv:2512.03416v2 Announce Type: replace Abstract: The architectural shift to prefill/decode (PD) disaggregation in LLM serving improves resource utilization but struggles with the bursty nature of modern workloads. Existing autoscaling policies, often retrofitted from monolithic systems like those in AIBrix and DistServe, rely on lagging indicators such as GPU utilization or coarse-grained request counts. This results in slow reactions to load spikes, leading to significant Time-to First-Token (TTFT) and Time-Per-Output-Token (TPOT) SLO violations and costly over-provisioning. We introduce TokenScale, an autoscaling framework that resolves this performance mismatch through two innovations. First, we propose Token Velocity, a novel metric that unifies the prefill, network, and decode stages by quantifying their rate of work. As a leading indicator of system backpressure, it enables proactive scaling. Second, Convertible Decoders allow decoder GPUs to dynamically execute prefill tasks during traffic spikes, creating a rapid-response buffer that absorbs bursts and eliminates the initialization latency of new prefillers. Our evaluation on a GPU cluster with production traces shows TokenScale improves SLO attainment from 50-88% to 80-96% and reduces costs by 4-14% over state-of-the-art systems, including DistServe, BlitzScale, and AIBrix. By uniting a predictive metric with a flexible system design, TokenScale significantly boosts the performance and efficiency of disaggregated LLM serving infrastructure.

## Retry storms: how the resilience layer became the outage

DevFeed: [Retry storms: how the resilience layer became the outage](<https://devfeed.tech/articles/retry-storms-how-the-resilience-layer-became-the-outage-119561.md>)

Original publisher: [Read original article](<https://ankit-rana.com/logs/72-retry-storms-resilience-became-the-outage/>)

Author: hello@ankit-rana.com

Published: 2026-11-05T00:00:00Z

Content type: article

Language: en

Sources: [Ankit Rana | Mechanical Sympathy](<https://devfeed.tech/sources/ankit-rana-mechanical-sympathy.md>)

Topics: [retry](<https://devfeed.tech/topics/retry.md>), [Resilience](<https://devfeed.tech/topics/resilience.md>), [rate-limiting](<https://devfeed.tech/topics/rate-limiting.md>), [service-mesh](<https://devfeed.tech/topics/service-mesh.md>)

Tags: [backpressure](<https://devfeed.tech/tags/backpressure.md>), [budget](<https://devfeed.tech/tags/budget.md>), [capacity](<https://devfeed.tech/tags/capacity.md>), [circuit-breaker](<https://devfeed.tech/tags/circuit-breaker.md>), [distributed-systems](<https://devfeed.tech/tags/distributed-systems.md>), [outage](<https://devfeed.tech/tags/outage.md>), [reliability](<https://devfeed.tech/tags/reliability.md>), [resilience](<https://devfeed.tech/tags/resilience.md>), [retries](<https://devfeed.tech/tags/retries.md>), [retry](<https://devfeed.tech/tags/retry.md>)

### AI overview

Retries configured independently across service layers multiply: two retries at both a gateway and service can send nine attempts to a dependency per original request, just as degradation leaves it least able to respond. That extra load can persist after the trigger is fixed and prevent recovery. The article recommends limiting retry ownership, using circuit breakers to fail fast and probe cautiously, and ensuring each inner layer's total retry time fits within its caller's timeout; propagated deadlines help enforce this. Per-request attempt limits do not bound aggregate load, so a retry budget tied to total traffic can cap amplification. Retry only plausibly transient failures, honor 429 responses and `Retry-After`, and use idempotency keys for writes such as charges. Add jitter to backoff. The text says Envoy and the gRPC ecosystem provide retry budgets, and gRPC natively propagates deadlines.

### Source excerpt

Retries configured independently at each hop multiply, so three layers each retrying three times means nine requests reaching the bottom for every one at the top. When a dependency degrades, that multiplier arrives exactly when it has least capacity, and the retries alone can keep it down after the original cause is gone. Per-call retry counts cannot bound this because no layer knows what the others are doing, which is why the useful control is a retry budget expressed as a fraction of total traffic.

## Your .NET parallel loop can become serial in a one-CPU container

DevFeed: [Your .NET parallel loop can become serial in a one-CPU container](<https://devfeed.tech/articles/your-net-parallel-loop-can-become-serial-in-a-one-cpu-container-118939.md>)

Original publisher: [Read original article](<https://stackoverflow.blog/2026/11/04/your-net-parallel-loop-can-become-serial-in-a-one-cpu-container/>)

Author: Guilherme Appel

Published: 2026-11-04T16:34:13Z

Content type: opinion

Language: en

Sources: [Stack Overflow](<https://devfeed.tech/sources/stack-overflow-blog.md>)

Topics: [Concurrency](<https://devfeed.tech/topics/concurrency.md>), [Distributed Systems & Parallel Computing](<https://devfeed.tech/topics/distributed-systems-parallel-computing.md>), [rate-limiting](<https://devfeed.tech/topics/rate-limiting.md>)

Tags: [ai](<https://devfeed.tech/tags/ai.md>), [api](<https://devfeed.tech/tags/api.md>), [backpressure](<https://devfeed.tech/tags/backpressure.md>), [budget](<https://devfeed.tech/tags/budget.md>), [building-software](<https://devfeed.tech/tags/building-software.md>), [capacity](<https://devfeed.tech/tags/capacity.md>), [cc-by-sa](<https://devfeed.tech/tags/cc-by-sa.md>), [concurrency](<https://devfeed.tech/tags/concurrency.md>), [container](<https://devfeed.tech/tags/container.md>), [contributed](<https://devfeed.tech/tags/contributed.md>), [cpu](<https://devfeed.tech/tags/cpu.md>), [dependencies](<https://devfeed.tech/tags/dependencies.md>), [i-o](<https://devfeed.tech/tags/i-o.md>), [net](<https://devfeed.tech/tags/net.md>), [parallel](<https://devfeed.tech/tags/parallel.md>), [serial](<https://devfeed.tech/tags/serial.md>), [service](<https://devfeed.tech/tags/service.md>)

### AI overview

In the lab, a one-CPU container cut the default Parallel.ForEachAsync concurrency from two records to one, nearly doubling the median time for 200 records from 42.1 to 83.6 seconds. The CPU-based default can constrain I/O work because it waits on a CPU-derived limit even while records await services. Raising the loop limit can restore concurrency but may overload downstream systems; a shared semaphore also cannot reserve capacity for a more fragile dependency, and it does not enforce rate quotas. The article recommends shared, explicit per-dependency concurrency budgets, configured to service capacity, with enough records in flight to meet throughput goals. In simulated tests, a six-write-permit budget eliminated HTTP 503 rejections when the write service slowed, while shared or absent limits produced 57-64; the per-dependency setup was slower in healthy runs and achieved about 0.82 of shared-pool throughput when enrichment slowed. These results describe simulated services. The article also recommends startup validation, per-service in-flight monitoring, separate call and permit-wait deadlines, and measurements under actual container CPU limits.

### Source excerpt

CPU-based defaults can leave an I/O-heavy loop processing one record at a time. Raising the limit helps, but each downstream service still needs a concurrency budget it can handle.

## Dispatch Control for Priority-Based, Multi-Tenant Workflows under Multi-Resource External Rate Limits

DevFeed: [Dispatch Control for Priority-Based, Multi-Tenant Workflows under Multi-Resource External Rate Limits](<https://devfeed.tech/articles/dispatch-control-for-priority-based-multi-tenant-workflows-under-multi-resource-external-rate-limits-113819.md>)

Original publisher: [Read original article](<https://arxiv.org/abs/2611.02926>)

Author: Stanislav Kosorin, Trever Schirmer, Leonard Wossnig, David Bermbach

Published: 2026-11-03T05:00:00Z

Content type: article

Language: en

Sources: [arXiv: Distributed Computing](<https://devfeed.tech/sources/arxiv-distributed-computing.md>)

Topics: [rate-limiting](<https://devfeed.tech/topics/rate-limiting.md>), [litellm](<https://devfeed.tech/topics/litellm.md>)

Tags: [admission](<https://devfeed.tech/tags/admission.md>), [ai-gateway](<https://devfeed.tech/tags/ai-gateway.md>), [apis](<https://devfeed.tech/tags/apis.md>), [backpressure](<https://devfeed.tech/tags/backpressure.md>), [cs-dc](<https://devfeed.tech/tags/cs-dc.md>), [dispatch](<https://devfeed.tech/tags/dispatch.md>), [fairness](<https://devfeed.tech/tags/fairness.md>), [latency](<https://devfeed.tech/tags/latency.md>), [limits](<https://devfeed.tech/tags/limits.md>), [litellm](<https://devfeed.tech/tags/litellm.md>), [priority](<https://devfeed.tech/tags/priority.md>), [releases](<https://devfeed.tech/tags/releases.md>), [temporal](<https://devfeed.tech/tags/temporal.md>), [timer](<https://devfeed.tech/tags/timer.md>), [tokens](<https://devfeed.tech/tags/tokens.md>), [worker](<https://devfeed.tech/tags/worker.md>), [workflows](<https://devfeed.tech/tags/workflows.md>)

### AI overview

Backpressure prevents rate-limited workflow calls from occupying worker slots while they wait to retry. Its worker-side admission gate atomically checks request and token costs against shared state; denied calls release their slots and wait on durable timers. In a three-priority workload, it raises Jain fairness from 0.60 to 0.89 and cuts high-priority tail latency roughly eightfold. When token limits bind, the request-based baselines serve priorities equally, while Backpressure preserves priority order and reaches about 0.99 dominant-resource fairness. Admission adds one shared-state round trip, with no measurable latency when limits do not bind; it fails open if shared state is unavailable. The abstract compares it with naive retries, LiteLLM, and Temporal's built-in throttle.

### Source excerpt

arXiv:2611.02926v1 Announce Type: new Abstract: Workflow engines orchestrate pipelines of activities, which often call external APIs, on a fixed pool of worker slots, the threads that run them. When an API enforces a hard rate limit shared by all tenants and priorities, a throttled call that retries after a backoff keeps its worker slot and starves other tenants. Large Language Model provider APIs are particularly complex: their per-organization caps are low and bind independently on requests and tokens per minute. The operator can neither reconfigure the cap nor observe saturation before a request fails, so classical fair-queuing assumptions do not hold. We present Backpressure, a worker-side admission gate. It checks each call's cost atomically against shared admission state and enforces fairness over requests and tokens. A denied call releases its worker slot and waits on a durable timer, so waiting no longer blocks execution capacity. We compare against a naive retry, the AI gateway LiteLLM, and the built-in throttle of the workflow engine Temporal. On a workload with three priority classes, Backpressure raises fairness (Jain's index over each queue's fraction of its entitled share) from 0.60 to 0.89, where 1.0 is ideal. It also cuts high-priority tail latency roughly 8x. When tokens are the binding limit, all request-based baselines serve every priority equally, whereas Backpressure keeps the priority order and reaches a dominant-resource fairness of ~0.99. Admission costs one round trip to shared state, adds no measurable latency when the cap does not bind, and fails open if shared state is unavailable.

## Part 1: Kotlin Flows -- The Air Compressor of Android (Fundamentals & Cold Streams)

DevFeed: [Part 1: Kotlin Flows -- The Air Compressor of Android (Fundamentals & Cold Streams)](<https://devfeed.tech/articles/part-1-kotlin-flows-the-air-compressor-of-android-fundamentals-cold-streams-88051.md>)

Original publisher: [Read original article](<https://proandroiddev.com/part-1-kotlin-flows-the-air-compressor-of-android-fundamentals-cold-streams-7ae94471c1d7?source=rss----c72404660798---4>)

Author: Sandeep Kella

Published: 2026-10-15T16:34:19Z

Content type: tutorial

Language: en

Sources: [ProAndroidDev](<https://devfeed.tech/sources/proandroiddev-medium.md>)

Topics: [Coroutines](<https://devfeed.tech/topics/coroutines.md>), [Kotlin](<https://devfeed.tech/topics/kotlin.md>), [Android](<https://devfeed.tech/topics/android.md>), [coroutines-flow](<https://devfeed.tech/topics/coroutines-flow.md>), [suspend function](<https://devfeed.tech/topics/suspend-function.md>)

Tags: [android](<https://devfeed.tech/tags/android.md>), [backpressure](<https://devfeed.tech/tags/backpressure.md>), [coroutine](<https://devfeed.tech/tags/coroutine.md>), [database](<https://devfeed.tech/tags/database.md>), [delay](<https://devfeed.tech/tags/delay.md>), [flow](<https://devfeed.tech/tags/flow.md>), [generate](<https://devfeed.tech/tags/generate.md>), [kotlin](<https://devfeed.tech/tags/kotlin.md>), [kotlin-flow](<https://devfeed.tech/tags/kotlin-flow.md>), [network](<https://devfeed.tech/tags/network.md>), [stream](<https://devfeed.tech/tags/stream.md>), [streams](<https://devfeed.tech/tags/streams.md>), [timer](<https://devfeed.tech/tags/timer.md>), [tool](<https://devfeed.tech/tags/tool.md>)

### AI overview

This tutorial introduces Kotlin Flow through an air-compressor analogy, explaining cold streams, collection, operators, cancellation, and backpressure. It also compares Flow with lists, LiveData, and RxJava, and discusses coroutine context and flowOn.

### Source excerpt

Hey! So you want to learn Kotlin Flows? Grab a seat. I know the official documentation can sometimes feel like reading a microwave manual, but I promise you, once you get the mental model right, Flows are going to be your best friend. Forget about the code for a second. Let's talk about air. The Breakdown: The Air Compressor Analogy Imagine you are painting a car using an Air Compressor and a Spray Gun. The Producer (The Compressor): This is where the air is generated. In Kotlin, this is your database, your network call, or a timer. The Flow (The Hose): This is the pipe connecting the compressor to your tool. The Operators (Valves & Filters): Maybe you have a moisture filter on the hose, or a pressure regulator. It modifies the air before it reaches you. The Consumer / Collector (The Spray Gun): This is your Android UI. Here is the most important concept to understand about a standard Kotlin Flow: It is a COLD stream. What does "Cold" mean? Imagine your air compressor is completely turned off and silent. It will not generate a single ounce of air until you pull the trigger on the spray gun. The moment you pull the trigger (in Kotlin, we call this .collect()), the compressor kicks on, air pushes through the filters, and paint comes out. When you let go of the trigger (cancel the coroutine), the whole system shuts down instantly. Diagrammatic Mental Model: Plaintext [Air Compressor] ---> (Pressure Valve) ---> (Moisture Filter) ---> [Spray Gun] (Producer) (Operator: map) (Operator: filter) (Collector) Status: DEAD SILENT until someone pulls the trigger on the Spray Gun. Let's look at how this looks in code: Kotlin // 1. The Compressor (Producer) val airFlow = flow { println("Compressor turned on!") emit("Air Burst 1") delay(1000) // Takes a second to build pressure emit("Air Burst 2") } // 2. The Trigger (Collector) // If we don't write this code below, the "Compressor turned on!" is NEVER printed. coroutineScope.launch { airFlow.collect { air -> println("Spray gun rec

## Virtual threads changed the calculus for blocking I/O and not for CPU work

DevFeed: [Virtual threads changed the calculus for blocking I/O and not for CPU work](<https://devfeed.tech/articles/virtual-threads-changed-the-calculus-for-blocking-i-o-and-not-for-cpu-work-87574.md>)

Original publisher: [Read original article](<https://ankit-rana.com/logs/66-virtual-threads-blocking-io-not-cpu/>)

Author: hello@ankit-rana.com

Published: 2026-10-15T00:00:00Z

Content type: article

Language: en

Sources: [Ankit Rana | Mechanical Sympathy](<https://devfeed.tech/sources/ankit-rana-mechanical-sympathy.md>)

Topics: [Distributed Systems & Parallel Computing](<https://devfeed.tech/topics/distributed-systems-parallel-computing.md>), [threadpools](<https://devfeed.tech/topics/threadpools.md>), [Deadlock](<https://devfeed.tech/topics/deadlock.md>), [performance-optimization](<https://devfeed.tech/topics/performance-optimization.md>)

Tags: [backpressure](<https://devfeed.tech/tags/backpressure.md>), [concurrency](<https://devfeed.tech/tags/concurrency.md>), [database](<https://devfeed.tech/tags/database.md>), [deadlock](<https://devfeed.tech/tags/deadlock.md>), [java](<https://devfeed.tech/tags/java.md>), [jvm](<https://devfeed.tech/tags/jvm.md>), [loom](<https://devfeed.tech/tags/loom.md>), [performance](<https://devfeed.tech/tags/performance.md>), [virtual-threads](<https://devfeed.tech/tags/virtual-threads.md>)

### AI overview

The article explains how Java virtual threads improve concurrency for services that spend much of their time waiting on blocking I/O, while providing no benefit for CPU-bound work. It discusses carrier pinning, avoiding virtual-thread pools, and placing concurrency limits at constrained downstream resources.

### Source excerpt

A virtual thread that blocks on I/O unmounts from its carrier and costs nothing while it waits, which makes thread-per-request viable at concurrency levels that would have needed reactive code. It does nothing for CPU bound work, because computation still needs a real core and the carrier pool is sized to the core count. Pooling virtual threads is an anti-pattern since they are cheap to create, and blocking inside a synchronized block pins the carrier, which can deadlock a workload that would have been fine on platform threads.

## Rewinding the exponential: How we keep hardware usage down

DevFeed: [Rewinding the exponential: How we keep hardware usage down](<https://devfeed.tech/articles/rewinding-the-exponential-how-we-keep-hardware-usage-down-86354.md>)

Original publisher: [Read original article](<https://blog.cloudflare.com/rewinding-the-exponential/>)

Author: Christian Endres

Published: 2026-10-13T15:51:41Z

Content type: article

Language: en

Sources: [Cloudflare Blog](<https://devfeed.tech/sources/cloudflare-blog.md>)

Topics: [Data Quality](<https://devfeed.tech/topics/data-quality.md>), [database-optimization](<https://devfeed.tech/topics/database-optimization.md>), [Compression](<https://devfeed.tech/topics/compression.md>), [cloud-infrastructure](<https://devfeed.tech/topics/cloud-infrastructure.md>)

Tags: [architecture](<https://devfeed.tech/tags/architecture.md>), [backpressure](<https://devfeed.tech/tags/backpressure.md>), [bandwidth](<https://devfeed.tech/tags/bandwidth.md>), [costs](<https://devfeed.tech/tags/costs.md>), [cpu](<https://devfeed.tech/tags/cpu.md>), [cpus](<https://devfeed.tech/tags/cpus.md>), [data](<https://devfeed.tech/tags/data.md>), [data-center](<https://devfeed.tech/tags/data-center.md>), [data-centers](<https://devfeed.tech/tags/data-centers.md>), [data-pipeline](<https://devfeed.tech/tags/data-pipeline.md>), [engineering](<https://devfeed.tech/tags/engineering.md>), [hardware](<https://devfeed.tech/tags/hardware.md>), [infrastructure](<https://devfeed.tech/tags/infrastructure.md>), [optimize](<https://devfeed.tech/tags/optimize.md>), [pipeline](<https://devfeed.tech/tags/pipeline.md>), [quality](<https://devfeed.tech/tags/quality.md>)

### AI overview

Cloudflare describes five years of changes to its data pipeline to manage exponential traffic growth against slower hardware growth. The changes include product-specific schemas, zstd compression, moving replication downstream of sampling, earlier sampling, and aggregation throughout the pipeline. The post reports substantial reductions in network traffic and resource use while aiming to preserve data quality.

### Source excerpt

Our strategies to optimize our data pipeline throughput without compromising data quality.

## Own Your Intelligence: Why Running Your Own AI Models Pays Off, and What It Really Takes

DevFeed: [Own Your Intelligence: Why Running Your Own AI Models Pays Off, and What It Really Takes](<https://devfeed.tech/articles/own-your-intelligence-why-running-your-own-ai-models-pays-off-and-what-it-really-takes-85135.md>)

Original publisher: [Read original article](<https://www.lyzr.ai/blog/own-your-intelligence/>)

Author: Lyzr Team

Published: 2026-10-10T09:02:30Z

Content type: article

Language: en

Sources: [Lyzr.ai](<https://devfeed.tech/sources/lyzr-ai.md>)

Topics: [AI Development](<https://devfeed.tech/topics/ai-development.md>), [on-prem](<https://devfeed.tech/topics/on-prem.md>), [Self Hosted AI Tools](<https://devfeed.tech/topics/self-hosted-ai-tools.md>), [LLM security](<https://devfeed.tech/topics/llm-security.md>), [Infrastructure as a Service (IaaS)](<https://devfeed.tech/topics/infrastructure-as-a-service-iaas.md>)

Tags: [ai](<https://devfeed.tech/tags/ai.md>), [ai-agents](<https://devfeed.tech/tags/ai-agents.md>), [ai-models](<https://devfeed.tech/tags/ai-models.md>), [autoscaling](<https://devfeed.tech/tags/autoscaling.md>), [backpressure](<https://devfeed.tech/tags/backpressure.md>), [concurrency](<https://devfeed.tech/tags/concurrency.md>), [cpu](<https://devfeed.tech/tags/cpu.md>), [embeddings](<https://devfeed.tech/tags/embeddings.md>), [gdpr](<https://devfeed.tech/tags/gdpr.md>), [it](<https://devfeed.tech/tags/it.md>), [servers](<https://devfeed.tech/tags/servers.md>)

### AI overview

The article explains the tradeoffs of running AI models on infrastructure a company controls, including data privacy, compliance, cost, model choice, and operational challenges. It discusses keeping retrieval and logs private, serving different models on limited GPUs, routing requests, handling concurrency and cold starts, and scaling based on model demand. The author reports that the described platform reduced cold starts from about 10 minutes to about 4 minutes and GPU costs by about 60%.

### Source excerpt

Most companies today rent their AI. Every prompt goes to someone else's model, on someone else's servers, at someone else's price. That's a great way...

## How New Relic engineers reliability at scale

DevFeed: [How New Relic engineers reliability at scale](<https://devfeed.tech/articles/how-new-relic-engineers-reliability-at-scale-84260.md>)

Original publisher: [Read original article](<https://newrelic.com/blog/observability/engineer-reliability-at-scale>)

Author: Kevin Scaldeferri

Published: 2026-10-09T12:00:00Z

Content type: article

Language: en

Sources: [New Relic](<https://devfeed.tech/sources/new-relic.md>)

Topics: [Production Engineering](<https://devfeed.tech/topics/production-engineering.md>), [Monitoring](<https://devfeed.tech/topics/monitoring.md>), [observability](<https://devfeed.tech/topics/observability.md>), [performance-engineering](<https://devfeed.tech/topics/performance-engineering.md>), [engineering-leadership](<https://devfeed.tech/topics/engineering-leadership.md>), [Integration testing](<https://devfeed.tech/topics/integration-testing.md>)

Tags: [alerting](<https://devfeed.tech/tags/alerting.md>), [architecture](<https://devfeed.tech/tags/architecture.md>), [automation](<https://devfeed.tech/tags/automation.md>), [backpressure](<https://devfeed.tech/tags/backpressure.md>), [blast-radius](<https://devfeed.tech/tags/blast-radius.md>), [cdn](<https://devfeed.tech/tags/cdn.md>), [cloud-infrastructure](<https://devfeed.tech/tags/cloud-infrastructure.md>), [code](<https://devfeed.tech/tags/code.md>), [configuration](<https://devfeed.tech/tags/configuration.md>), [expert-observability](<https://devfeed.tech/tags/expert-observability.md>), [improve-real-user-experience](<https://devfeed.tech/tags/improve-real-user-experience.md>), [improve-reliability](<https://devfeed.tech/tags/improve-reliability.md>), [reliability](<https://devfeed.tech/tags/reliability.md>), [resilient-architecture](<https://devfeed.tech/tags/resilient-architecture.md>), [scale](<https://devfeed.tech/tags/scale.md>), [telemetry](<https://devfeed.tech/tags/telemetry.md>)

### AI overview

New Relic describes how it improves reliability across its platform by tracking incident and customer impact metrics, designing for resilience, and automating detection and response. Its practices include cell architecture, multi-CDN failover, infrastructure monitoring, alert coverage, end-to-end synthetic checks, change tracking, and AI-assisted incident investigation.

### Source excerpt

Learn how New Relicengineers reliability at scale with telemetry, resilient architecture, and automation to detect, contain and respond to failure.

## Thundering herd of circuit breakers

DevFeed: [Thundering herd of circuit breakers](<https://devfeed.tech/articles/thundering-herd-of-circuit-breakers-76983.md>)

Original publisher: [Read original article](<https://engineering.zalando.com/posts/2026/10/thundering-herd-of-circuit-breakers.html>)

Author: Valeria Ponyaeva

Published: 2026-10-07T22:00:00Z

Content type: article

Language: en

Sources: [Zalando](<https://devfeed.tech/sources/zalando-engineering-blog.md>)

Topics: [OpenTelemetry](<https://devfeed.tech/topics/opentelemetry.md>), [Data visualization](<https://devfeed.tech/topics/data-visualization.md>), [Grafana](<https://devfeed.tech/topics/grafana.md>), [Test-driven development](<https://devfeed.tech/topics/tdd.md>), [container image compliance](<https://devfeed.tech/topics/container-image-compliance.md>), [rate-limiting](<https://devfeed.tech/topics/rate-limiting.md>)

Tags: [auto-scaling](<https://devfeed.tech/tags/auto-scaling.md>), [backend](<https://devfeed.tech/tags/backend.md>), [backpressure](<https://devfeed.tech/tags/backpressure.md>), [capacity](<https://devfeed.tech/tags/capacity.md>), [circuit](<https://devfeed.tech/tags/circuit.md>), [concurrency](<https://devfeed.tech/tags/concurrency.md>), [data-visualization](<https://devfeed.tech/tags/data-visualization.md>), [microservices](<https://devfeed.tech/tags/microservices.md>), [monitoring](<https://devfeed.tech/tags/monitoring.md>), [opentelemetry](<https://devfeed.tech/tags/opentelemetry.md>), [sre](<https://devfeed.tech/tags/sre.md>), [thundering-herd](<https://devfeed.tech/tags/thundering-herd.md>), [trace](<https://devfeed.tech/tags/trace.md>), [zalando](<https://devfeed.tech/tags/zalando.md>)

### AI overview

A circuit breaker repeatedly closed after successful low-volume probes, then released queued traffic in a burst that overwhelmed a service scaled down to its minimum. OpenTelemetry traces visualized in a custom tool exposed the cycle, while pre-scaling helped the service absorb traffic and remain stable. The article also discusses autoscaling, probing, backpressure, and cancellation handling as ways to reduce the failure loop.

### Source excerpt

A client-side circuit breaker stays open for hours, blocking 95% of traffic, and won't close. Our service shows no sign of being unhealthy. To understand the anomaly, we build a custom span visualizer on top of OpenTelemetry trace data and find a circuit breaker trap that our existing dashboards don't reveal.

## Introducing GraphOS Router 3.0

DevFeed: [Introducing GraphOS Router 3.0](<https://devfeed.tech/articles/introducing-graphos-router-3-0-66629.md>)

Original publisher: [Read original article](<https://www.apollographql.com/blog/introducing-graphos-router-3-0>)

Author: Matthew Ratzke

Published: 2026-10-07T11:31:00Z

Content type: release

Language: en

Sources: [Apollo Blog](<https://devfeed.tech/sources/apollo-blog.md>)

Topics: [GraphOS](<https://devfeed.tech/topics/graphos.md>), [GraphQL](<https://devfeed.tech/topics/graphql.md>), [rate-limiting](<https://devfeed.tech/topics/rate-limiting.md>), [Deployment Strategies](<https://devfeed.tech/topics/deployment-strategies.md>)

Tags: [announcement](<https://devfeed.tech/tags/announcement.md>), [apollo-connectors](<https://devfeed.tech/tags/apollo-connectors.md>), [backpressure](<https://devfeed.tech/tags/backpressure.md>), [deployment](<https://devfeed.tech/tags/deployment.md>), [distributed](<https://devfeed.tech/tags/distributed.md>), [graphos](<https://devfeed.tech/tags/graphos.md>), [preview](<https://devfeed.tech/tags/preview.md>), [query](<https://devfeed.tech/tags/query.md>)

### AI overview

GraphOS Router 3.0 is available in Preview with changes to query planning, deployment, request processing, resilience, and GraphQL specification support. The release adds packaged persisted queries, native circuit breaking, and planned distributed rate limiting, alongside a redesigned request pipeline and performance improvements.

### Source excerpt

GraphOS Router 3.0 brings faster query planning, greater deployment control, native circuit breaking, and more. Try it in Preview today.

## I Built an OpenTelemetry Logs Bridge. Encoding Was the Easy Part

DevFeed: [I Built an OpenTelemetry Logs Bridge. Encoding Was the Easy Part](<https://devfeed.tech/articles/i-built-an-opentelemetry-logs-bridge-encoding-was-the-easy-part-66479.md>)

Original publisher: [Read original article](<https://hackernoon.com/i-built-an-opentelemetry-logs-bridge-encoding-was-the-easy-part?source=rss>)

Author: Admilson Cossa

Published: 2026-10-06T21:07:43Z

Content type: article

Language: en

Sources: [HackerNoon](<https://devfeed.tech/sources/hackernoon.md>)

Topics: [OpenTelemetry](<https://devfeed.tech/topics/opentelemetry.md>), [telemetry](<https://devfeed.tech/topics/telemetry.md>)

Tags: [backpressure](<https://devfeed.tech/tags/backpressure.md>), [build](<https://devfeed.tech/tags/build.md>), [go-logging](<https://devfeed.tech/tags/go-logging.md>), [halolog](<https://devfeed.tech/tags/halolog.md>), [logs](<https://devfeed.tech/tags/logs.md>), [microbenchmarking](<https://devfeed.tech/tags/microbenchmarking.md>), [observability-engineering](<https://devfeed.tech/tags/observability-engineering.md>), [opentelemetry](<https://devfeed.tech/tags/opentelemetry.md>), [opentelemetry-logs](<https://devfeed.tech/tags/opentelemetry-logs.md>), [opentelemetry-sdk](<https://devfeed.tech/tags/opentelemetry-sdk.md>), [structured-logging](<https://devfeed.tech/tags/structured-logging.md>), [telemetry-pipelines](<https://devfeed.tech/tags/telemetry-pipelines.md>)

### AI overview

The article details an OpenTelemetry Logs bridge for HaloLog, focusing on contracts that govern correct and safe log export. It explains how the bridge preserves filtering context, ensures masking remains authoritative, copies byte values so retained records survive pooled-entry reuse, and handles provider flushing without shutting down application-owned telemetry. It also describes allocation boundaries, tests designed to expose broken guarantees, release validation, and limitations such as untested remote collectors and non-guaranteed lossless delivery.

### Source excerpt

An OpenTelemetry Logs bridge for HaloLog exposed harder contracts around context, masking, retained bytes, provider lifecycle, and allocation boundaries.

## How savepoints quietly throttled our Postgres queue

DevFeed: [How savepoints quietly throttled our Postgres queue](<https://devfeed.tech/articles/how-savepoints-quietly-throttled-our-postgres-queue-66833.md>)

Original publisher: [Read original article](<https://incident.io/blog/how-savepoints-quietly-throttled-our-postgres-queue>)

Author: Rory Malcolm

Published: 2026-10-06T20:35:15Z

Content type: article

Language: en

Sources: [The incident.io Blog](<https://devfeed.tech/sources/the-incident-io-blog.md>)

Topics: [database-optimization](<https://devfeed.tech/topics/database-optimization.md>), [performance-engineering](<https://devfeed.tech/topics/performance-engineering.md>), [queueing theory](<https://devfeed.tech/topics/queueing-theory.md>), [scalable-architecture](<https://devfeed.tech/topics/scalable-architecture.md>), [locking](<https://devfeed.tech/topics/locking.md>), [rate-limiting](<https://devfeed.tech/topics/rate-limiting.md>), [Deployment Strategies](<https://devfeed.tech/topics/deployment-strategies.md>)

Tags: [backpressure](<https://devfeed.tech/tags/backpressure.md>), [blocking](<https://devfeed.tech/tags/blocking.md>), [bottlenecks](<https://devfeed.tech/tags/bottlenecks.md>), [cache](<https://devfeed.tech/tags/cache.md>), [concurrent](<https://devfeed.tech/tags/concurrent.md>), [database](<https://devfeed.tech/tags/database.md>), [delay](<https://devfeed.tech/tags/delay.md>), [dispatcher](<https://devfeed.tech/tags/dispatcher.md>), [distributed](<https://devfeed.tech/tags/distributed.md>), [incident](<https://devfeed.tech/tags/incident.md>), [incident-channel](<https://devfeed.tech/tags/incident-channel.md>), [incident-management](<https://devfeed.tech/tags/incident-management.md>), [incident-response](<https://devfeed.tech/tags/incident-response.md>), [internals](<https://devfeed.tech/tags/internals.md>), [outage](<https://devfeed.tech/tags/outage.md>), [performance](<https://devfeed.tech/tags/performance.md>), [post-mortem](<https://devfeed.tech/tags/post-mortem.md>), [postgres](<https://devfeed.tech/tags/postgres.md>), [slack-incident](<https://devfeed.tech/tags/slack-incident.md>)

### AI overview

The incident.io team improved a Postgres-backed escalation queue by addressing tuple churn, MultiXact lock contention caused by per-tick savepoints, and repeated worker claim scans. They separated job claiming from processing, used a per-pod dispatcher with buffered worker channels, and tuned HOT updates and vacuuming. Load tests showed 3.5x peak escalation throughput, with a tradeoff of up to 10 seconds of delay if a process dies after claiming a job.

### Source excerpt

We 3.5x'd our peak capacity in one of the most performance critical systems we have; here's how we did it, featuring a journey through some Postgres internals.

## Stragglers, Synchronization, and Stalled GPUs: How Enterprise AI Training Fails Quietly

DevFeed: [Stragglers, Synchronization, and Stalled GPUs: How Enterprise AI Training Fails Quietly](<https://devfeed.tech/articles/stragglers-synchronization-and-stalled-gpus-how-enterprise-ai-training-fails-quietly-78034.md>)

Original publisher: [Read original article](<https://wf.coreweave.com/blog/stragglers-synchronization-and-stalled-gpus-how-enterprise-ai-training-fails-quietly>)

Author: CoreWeave

Published: 2026-10-02T14:12:41Z

Content type: article

Language: en

Sources: [Coreweave Blog Posts](<https://devfeed.tech/sources/coreweave-blog-posts.md>)

Topics: [distributed-training](<https://devfeed.tech/topics/distributed-training.md>), [AI Infrastructure](<https://devfeed.tech/topics/ai-infrastructure.md>), [synchronization](<https://devfeed.tech/topics/synchronization.md>), [scaling laws](<https://devfeed.tech/topics/scaling-laws.md>)

Tags: [ai](<https://devfeed.tech/tags/ai.md>), [ai-infrastructure](<https://devfeed.tech/tags/ai-infrastructure.md>), [ai-model-training](<https://devfeed.tech/tags/ai-model-training.md>), [backpressure](<https://devfeed.tech/tags/backpressure.md>), [bottlenecks](<https://devfeed.tech/tags/bottlenecks.md>), [clusters](<https://devfeed.tech/tags/clusters.md>), [content-type](<https://devfeed.tech/tags/content-type.md>), [coreweave](<https://devfeed.tech/tags/coreweave.md>), [cost](<https://devfeed.tech/tags/cost.md>), [cycles](<https://devfeed.tech/tags/cycles.md>), [gpu](<https://devfeed.tech/tags/gpu.md>), [gpus](<https://devfeed.tech/tags/gpus.md>)

### AI overview

Large-scale distributed AI training can quietly waste GPU capacity when stragglers, communication stalls, or delays in storage, checkpointing, and scheduling slow progress. The article outlines workload-level signals for diagnosing these issues and presents CoreWeave Cloud's infrastructure and observability capabilities as ways to reduce coordination failures.

### Source excerpt

Large-scale AI training can fail quietly when stragglers, stalls, and wasted GPU cycles slow progress. CoreWeave helps teams turn compute into predictable model advancement.

## Key metrics for monitoring Databricks

DevFeed: [Key metrics for monitoring Databricks](<https://devfeed.tech/articles/key-metrics-for-monitoring-databricks-64040.md>)

Original publisher: [Read original article](<https://www.datadoghq.com/blog/key-metrics-for-databricks-monitoring/>)

Author: Aaron Kaplan; Ryan Warrier

Published: 2026-10-02T00:00:00Z

Content type: tutorial

Language: en

Sources: [Datadog](<https://devfeed.tech/sources/datadog-the-monitor-blog.md>)

Topics: [databricks](<https://devfeed.tech/topics/databricks.md>), [Monitoring](<https://devfeed.tech/topics/monitoring.md>), [database monitoring](<https://devfeed.tech/topics/database-monitoring.md>), [AI Infrastructure](<https://devfeed.tech/topics/ai-infrastructure.md>)

Tags: [ai-workloads](<https://devfeed.tech/tags/ai-workloads.md>), [autoscaling](<https://devfeed.tech/tags/autoscaling.md>), [backpressure](<https://devfeed.tech/tags/backpressure.md>), [capacity](<https://devfeed.tech/tags/capacity.md>), [clusters](<https://devfeed.tech/tags/clusters.md>), [concurrency](<https://devfeed.tech/tags/concurrency.md>), [costs](<https://devfeed.tech/tags/costs.md>), [data-engineering](<https://devfeed.tech/tags/data-engineering.md>), [data-jobs-monitoring](<https://devfeed.tech/tags/data-jobs-monitoring.md>), [data-observability](<https://devfeed.tech/tags/data-observability.md>), [databricks](<https://devfeed.tech/tags/databricks.md>), [metrics](<https://devfeed.tech/tags/metrics.md>), [monitoring](<https://devfeed.tech/tags/monitoring.md>), [performance](<https://devfeed.tech/tags/performance.md>)

### AI overview

The article outlines metrics for monitoring Databricks data engineering, analytics, streaming, SQL warehouse, and Model Serving workloads. It discusses signals for job failures and duration, pipeline errors, Spark memory pressure and disk spill, query latency and capacity, streaming backpressure, compute health, endpoint errors and latency, GPU memory, concurrency, and cost anomalies.

### Source excerpt

Learn about key metrics for monitoring the health, performance, and costs of Databricks data engineering, analytics, and Model Serving workloads.

## Control Planes, Part 2: When to Stop Configuring Autoscalers and Build Your Own

DevFeed: [Control Planes, Part 2: When to Stop Configuring Autoscalers and Build Your Own](<https://devfeed.tech/articles/control-planes-part-2-when-to-stop-configuring-autoscalers-and-build-your-own-63970.md>)

Original publisher: [Read original article](<https://hackernoon.com/control-planes-part-2-when-to-stop-configuring-autoscalers-and-build-your-own?source=rss>)

Author: Varsha Ganesh

Published: 2026-10-01T23:56:56Z

Content type: article

Language: en

Sources: [HackerNoon](<https://devfeed.tech/sources/hackernoon.md>)

Topics: [control-plane](<https://devfeed.tech/topics/control-plane.md>), [Distributed Systems & Parallel Computing](<https://devfeed.tech/topics/distributed-systems-parallel-computing.md>), [Amazon DynamoDB](<https://devfeed.tech/topics/amazon-dynamodb.md>)

Tags: [autoscaling](<https://devfeed.tech/tags/autoscaling.md>), [aws](<https://devfeed.tech/tags/aws.md>), [backpressure](<https://devfeed.tech/tags/backpressure.md>), [control-plane](<https://devfeed.tech/tags/control-plane.md>), [distributed-architecture](<https://devfeed.tech/tags/distributed-architecture.md>), [distributed-systems](<https://devfeed.tech/tags/distributed-systems.md>), [hackernoon-top-story](<https://devfeed.tech/tags/hackernoon-top-story.md>), [kubernetes](<https://devfeed.tech/tags/kubernetes.md>), [scaling](<https://devfeed.tech/tags/scaling.md>), [software-architecture](<https://devfeed.tech/tags/software-architecture.md>), [software-engineering](<https://devfeed.tech/tags/software-engineering.md>)

### AI overview

The article explains AWS, managed database, and Kubernetes autoscaling, emphasizing metrics that reflect actual bottlenecks. It argues that standard autoscalers generally suit interchangeable, stateless workloads, while stateful or partitioned systems may need custom scaling logic. A bespoke scaler needs resource-aware monitoring, a decision engine, safe execution, backpressure, and observability.

### Source excerpt

How to scale distributed systems: cloud-native autoscaling, Kubernetes scalers, managed database autoscaling, and when to build your own.

## A resilient kernel log reporter

DevFeed: [A resilient kernel log reporter](<https://devfeed.tech/articles/a-resilient-kernel-log-reporter-63556.md>)

Original publisher: [Read original article](<https://blog.janestreet.com/linux-engineering-kernel-reporter-index/>)

Author: Varun Gupta

Published: 2026-10-01T00:00:00Z

Content type: article

Language: en

Sources: [Jane Street](<https://devfeed.tech/sources/jane-street.md>)

Topics: [Kernel](<https://devfeed.tech/topics/kernel.md>), [Linux](<https://devfeed.tech/topics/linux.md>), [log management](<https://devfeed.tech/topics/log-management.md>), [Cloud Logging](<https://devfeed.tech/topics/cloud-logging.md>)

Tags: [analysis](<https://devfeed.tech/tags/analysis.md>), [backend](<https://devfeed.tech/tags/backend.md>), [backpressure](<https://devfeed.tech/tags/backpressure.md>), [capture](<https://devfeed.tech/tags/capture.md>), [cause](<https://devfeed.tech/tags/cause.md>), [chrome](<https://devfeed.tech/tags/chrome.md>), [cli](<https://devfeed.tech/tags/cli.md>), [collection](<https://devfeed.tech/tags/collection.md>), [debug](<https://devfeed.tech/tags/debug.md>), [device](<https://devfeed.tech/tags/device.md>), [dns](<https://devfeed.tech/tags/dns.md>), [file](<https://devfeed.tech/tags/file.md>), [filesystem](<https://devfeed.tech/tags/filesystem.md>), [internship](<https://devfeed.tech/tags/internship.md>), [kernel](<https://devfeed.tech/tags/kernel.md>)

### AI overview

A Linux log shipper collects kernel logs without depending on local disk or network availability. The project also uses pstore to preserve panic logs for transfer after reboot, then exposes them through command-line tools to help diagnose crashes, including failures associated with a recent Nvidia driver update.

### Source excerpt

The following is part of a series of posts about 2026 summer intern projects--for more, see "What the interns have wrought, special jumbo 2026 edition"

## Backpressure is not rate limiting, and treating them the same fills your queues

DevFeed: [Backpressure is not rate limiting, and treating them the same fills your queues](<https://devfeed.tech/articles/backpressure-is-not-rate-limiting-and-treating-them-the-same-fills-your-queues-63064.md>)

Original publisher: [Read original article](<https://ankit-rana.com/logs/61-backpressure-is-not-rate-limiting/>)

Author: hello@ankit-rana.com

Published: 2026-10-01T00:00:00Z

Content type: article

Language: en

Sources: [Ankit Rana | Mechanical Sympathy](<https://devfeed.tech/sources/ankit-rana-mechanical-sympathy.md>)

Topics: [backpressure](<https://devfeed.tech/topics/backpressure.md>), [rate-limiting](<https://devfeed.tech/topics/rate-limiting.md>), [Reactive Streams](<https://devfeed.tech/topics/reactive-streams.md>)

Tags: [backpressure](<https://devfeed.tech/tags/backpressure.md>), [distributed-systems](<https://devfeed.tech/tags/distributed-systems.md>), [latency](<https://devfeed.tech/tags/latency.md>), [memory](<https://devfeed.tech/tags/memory.md>), [queues](<https://devfeed.tech/tags/queues.md>), [rate-limiting](<https://devfeed.tech/tags/rate-limiting.md>), [reliability](<https://devfeed.tech/tags/reliability.md>), [resilience](<https://devfeed.tech/tags/resilience.md>)

### AI overview

The article distinguishes rate limiting, which applies a fixed policy ceiling, from backpressure, which communicates current capacity constraints upstream. It explains how unbounded queues turn overload into latency and memory failures, and discusses bounded queues, rejection policies, HTTP status codes, flow control, load shedding, and deadlines as ways to manage overload.

### Source excerpt

Rate limiting enforces a fixed ceiling chosen in advance, which protects you from a producer that sends too much and does nothing when your own capacity drops. Backpressure is a signal travelling backwards from the component that is actually struggling, so the allowed rate tracks real capacity instead of a guess. The thing that defeats both is an unbounded queue, because it absorbs the overload silently and converts a fast rejection into unbounded latency and eventually a memory failure.

## Streaming Encrypted Files P2P with WebRTC DataChannels and WebCrypto in TypeScript

DevFeed: [Streaming Encrypted Files P2P with WebRTC DataChannels and WebCrypto in TypeScript](<https://devfeed.tech/articles/streaming-encrypted-files-p2p-with-webrtc-datachannels-and-webcrypto-in-typescript-55359.md>)

Original publisher: [Read original article](<https://www.sitepoint.com/streaming-encrypted-files-p2p-webrtc-datachannels-webcrypto-typescript/>)

Author: SitePoint Team

Published: 2026-09-19T14:38:08Z

Content type: tutorial

Language: en

Sources: [SitePoint](<https://devfeed.tech/sources/sitepoint.md>)

Topics: [P2P](<https://devfeed.tech/topics/p2p.md>), [WebRTC](<https://devfeed.tech/topics/webrtc.md>), [backpressure](<https://devfeed.tech/topics/backpressure.md>), [Encryption](<https://devfeed.tech/topics/encryption.md>), [TypeScript](<https://devfeed.tech/topics/typescript.md>), [browser](<https://devfeed.tech/topics/browser.md>), [file](<https://devfeed.tech/topics/file.md>), [software-development](<https://devfeed.tech/topics/software-development.md>), [Cryptography](<https://devfeed.tech/topics/cryptography.md>), [Streams](<https://devfeed.tech/topics/streams.md>), [data](<https://devfeed.tech/topics/data.md>), [API](<https://devfeed.tech/topics/api.md>)

Tags: [api](<https://devfeed.tech/tags/api.md>), [backpressure](<https://devfeed.tech/tags/backpressure.md>), [build](<https://devfeed.tech/tags/build.md>), [development](<https://devfeed.tech/tags/development.md>), [download](<https://devfeed.tech/tags/download.md>), [encrypted](<https://devfeed.tech/tags/encrypted.md>), [encryption](<https://devfeed.tech/tags/encryption.md>), [end-to-end-encryption](<https://devfeed.tech/tags/end-to-end-encryption.md>), [file](<https://devfeed.tech/tags/file.md>), [javascript](<https://devfeed.tech/tags/javascript.md>), [p2p](<https://devfeed.tech/tags/p2p.md>), [programming](<https://devfeed.tech/tags/programming.md>), [sha-256](<https://devfeed.tech/tags/sha-256.md>), [streams](<https://devfeed.tech/tags/streams.md>), [tutorial](<https://devfeed.tech/tags/tutorial.md>), [typescript](<https://devfeed.tech/tags/typescript.md>), [vite](<https://devfeed.tech/tags/vite.md>), [web-security](<https://devfeed.tech/tags/web-security.md>), [webrtc](<https://devfeed.tech/tags/webrtc.md>), [websocket](<https://devfeed.tech/tags/websocket.md>)

### AI overview

A tutorial for building a serverless, browser-based peer-to-peer file-transfer engine using WebRTC DataChannels and WebCrypto. It covers chunked streaming, backpressure, per-chunk AES-GCM encryption, and SHA-256 integrity verification in TypeScript.

### Source excerpt

Build a serverless P2P browser file-transfer engine with WebRTC DataChannels, bufferedAmountLowThreshold backpressure, and AES-GCM encryption via WebCrypto. Continue reading Streaming Encrypted Files P2P with WebRTC DataChannels and WebCrypto in TypeScript on SitePoint.

## Worker Backpressure (Part 1)

DevFeed: [Worker Backpressure (Part 1)](<https://devfeed.tech/articles/worker-backpressure-part-1-37935.md>)

Original publisher: [Read original article](<https://www.canva.dev/blog/engineering/worker-backpressure-part-1-how-we-taught-our-queue-workers-to-slow-down/>)

Author: Mikalai Barysau

Published: 2026-09-17T00:00:00Z

Content type: article

Language: en

Sources: [Canva Engineering](<https://devfeed.tech/sources/canva-engineering.md>)

Topics: [backpressure](<https://devfeed.tech/topics/backpressure.md>), [Back end](<https://devfeed.tech/topics/backend.md>), [reliability-engineering](<https://devfeed.tech/topics/reliability-engineering.md>)

Tags: [backend](<https://devfeed.tech/tags/backend.md>), [backpressure](<https://devfeed.tech/tags/backpressure.md>), [dependencies](<https://devfeed.tech/tags/dependencies.md>), [outage](<https://devfeed.tech/tags/outage.md>), [queue](<https://devfeed.tech/tags/queue.md>), [reliability](<https://devfeed.tech/tags/reliability.md>), [worker](<https://devfeed.tech/tags/worker.md>)

### AI overview

Canva describes Worker Backpressure, a reliability mechanism for queue workers that slows processing when dependencies fail and speeds it back up after recovery. During a cloud-provider outage, the mechanism helped prevent failed messages from accumulating on the Dead Letter Queue and avoided an on-call page.

### Source excerpt

How we taught Canva's queue workers to slow down when dependencies fail, then speed back up on their own.

## Rust AI Agent Gateway: Build Low-Latency SSE Streaming in Axum

DevFeed: [Rust AI Agent Gateway: Build Low-Latency SSE Streaming in Axum](<https://devfeed.tech/articles/rust-ai-agent-gateway-build-low-latency-sse-streaming-in-axum-50877.md>)

Original publisher: [Read original article](<https://www.sitepoint.com/rust-ai-agent-gateway-sse-streaming-axum/>)

Author: SitePoint Team

Published: 2026-09-10T19:34:46Z

Content type: tutorial

Language: en

Sources: [SitePoint](<https://devfeed.tech/sources/sitepoint.md>)

Topics: [Rust](<https://devfeed.tech/topics/rust.md>), [Artificial Intelligence](<https://devfeed.tech/topics/ai.md>), [gateway](<https://devfeed.tech/topics/gateway.md>), [Server-sent events (SSE)](<https://devfeed.tech/topics/server-sent-events-sse.md>), [Streaming](<https://devfeed.tech/topics/streaming.md>), [Tokio](<https://devfeed.tech/topics/tokio.md>), [Latency](<https://devfeed.tech/topics/latency.md>), [async](<https://devfeed.tech/topics/async.md>), [Redis](<https://devfeed.tech/topics/redis.md>), [Concurrency](<https://devfeed.tech/topics/concurrency.md>), [backpressure](<https://devfeed.tech/topics/backpressure.md>)

Tags: [agent-gateway](<https://devfeed.tech/tags/agent-gateway.md>), [ai](<https://devfeed.tech/tags/ai.md>), [apis](<https://devfeed.tech/tags/apis.md>), [async](<https://devfeed.tech/tags/async.md>), [backpressure](<https://devfeed.tech/tags/backpressure.md>), [cancellation](<https://devfeed.tech/tags/cancellation.md>), [concurrency](<https://devfeed.tech/tags/concurrency.md>), [latency](<https://devfeed.tech/tags/latency.md>), [low-latency](<https://devfeed.tech/tags/low-latency.md>), [programming](<https://devfeed.tech/tags/programming.md>), [rust](<https://devfeed.tech/tags/rust.md>), [server-sent-events-sse](<https://devfeed.tech/tags/server-sent-events-sse.md>), [streaming](<https://devfeed.tech/tags/streaming.md>), [tokio](<https://devfeed.tech/tags/tokio.md>)

### AI overview

A tutorial on building a production-oriented AI agent gateway in Rust with Axum, Tokio, Redis, and Server-Sent Events. It covers asynchronous turn orchestration, concurrent tool dispatch, durable conversation state, pub/sub fan-out, cancellation, backpressure, observability, and k6 benchmarking.

### Source excerpt

Construct a high-throughput, low-latency AI agent gateway in Rust using Tokio, Axum, and Server-Sent Events (SSE). Continue reading Rust AI Agent Gateway: Build Low-Latency SSE Streaming in Axum on SitePoint.

## Consumer Not Found: Kafka, SQS, and QStash on Serverless

DevFeed: [Consumer Not Found: Kafka, SQS, and QStash on Serverless](<https://devfeed.tech/articles/consumer-not-found-kafka-sqs-and-qstash-on-serverless-78687.md>)

Original publisher: [Read original article](<https://upstash.com/blog/kafka-sqs-qstash-serverless-order-pipeline>)

Author: Sancar Koyunlu

Published: 2026-09-09T00:00:00Z

Content type: comparison

Language: en

Sources: [Upstash](<https://devfeed.tech/sources/upstash.md>)

Topics: [Serverless](<https://devfeed.tech/topics/serverless.md>), [Apache Kafka](<https://devfeed.tech/topics/apache-kafka.md>), [Amazon Simple Queue Service (SQS)](<https://devfeed.tech/topics/amazon-simple-queue-service-sqs.md>), [Publish-subscribe pattern](<https://devfeed.tech/topics/pubsub.md>)

Tags: [amazon-sqs](<https://devfeed.tech/tags/amazon-sqs.md>), [aws-lambda](<https://devfeed.tech/tags/aws-lambda.md>), [backpressure](<https://devfeed.tech/tags/backpressure.md>), [blocking](<https://devfeed.tech/tags/blocking.md>), [cron](<https://devfeed.tech/tags/cron.md>), [delivered](<https://devfeed.tech/tags/delivered.md>), [kafka](<https://devfeed.tech/tags/kafka.md>), [qstash](<https://devfeed.tech/tags/qstash.md>), [serverless](<https://devfeed.tech/tags/serverless.md>), [sqs](<https://devfeed.tech/tags/sqs.md>)

### AI overview

The article builds the same order-processing pipeline with Kafka, Amazon SQS, and QStash for a serverless Next.js store, comparing implementation and ongoing operational work. Kafka requires a persistent consumer process, while SQS relies on polling and AWS Lambda event source mappings; QStash sends HTTP requests to existing app routes. It also outlines cases where Kafka or SQS may fit better, including replayable event streams and workloads already running on AWS.

### Source excerpt

Let's build the same order pipeline three times, with Kafka, Amazon SQS, and QStash, and see what it takes to maintain each one when your app is serverless.

## Bun v1.4.1

DevFeed: [Bun v1.4.1](<https://devfeed.tech/articles/bun-v1-4-1-49463.md>)

Original publisher: [Read original article](<https://bun.com/blog/bun-v1.4.1>)

Author: Jarred Sumner

Published: 2026-09-04T06:47:12Z

Content type: release

Language: en

Sources: [Bun](<https://devfeed.tech/sources/bun-com.md>)

Topics: [Bun](<https://devfeed.tech/topics/bun.md>), [HTTP](<https://devfeed.tech/topics/http.md>), [Streams](<https://devfeed.tech/topics/streams.md>), [WebSocket](<https://devfeed.tech/topics/websocket.md>), [Node.js](<https://devfeed.tech/topics/node-js.md>)

Tags: [backpressure](<https://devfeed.tech/tags/backpressure.md>), [blog](<https://devfeed.tech/tags/blog.md>), [bugfixes](<https://devfeed.tech/tags/bugfixes.md>), [bun](<https://devfeed.tech/tags/bun.md>), [compatibility](<https://devfeed.tech/tags/compatibility.md>), [http](<https://devfeed.tech/tags/http.md>), [js](<https://devfeed.tech/tags/js.md>), [streams](<https://devfeed.tech/tags/streams.md>), [v1](<https://devfeed.tech/tags/v1.md>), [websocket](<https://devfeed.tech/tags/websocket.md>)

### AI overview

Bun v1.4.1 is a release focused on bug fixes, HTTP/2 support, lower idle memory use, streaming response bodies to disk, WebSocket flow control, improved Node.js compatibility, and performance improvements across I/O and runtime features.

### Source excerpt

Fixes 202 issues, addressing 236 👍. HTTP/2 in Bun.serve, Bun.write() streams Response bodies to disk, self-contained workspace node_modules, bun install --offline and --prefer-offline, WebSocket pause() and resume(), crypto.argon2, tree-shaking through dynamic import(), smarter CommonJS to ESM conversion for default imports, --compile --bytecode when cross-compiling, smaller and faster-starting compiled executables, up to 9x faster Buffer reads and writes, 2x faster AsyncLocalStorage, faster startup, and many bugfixes and Node.js compatibility improvements.

## Broadcasting to 28K SSE Clients (and learning about Go channels)

DevFeed: [Broadcasting to 28K SSE Clients (and learning about Go channels)](<https://devfeed.tech/articles/broadcasting-to-28k-sse-clients-and-learning-about-go-channels-39405.md>)

Original publisher: [Read original article](<https://blog.pranshu-raj.in/posts/implementing-correct-fanout/>)

Author: Pranshu Raj

Published: 2026-07-23T00:00:00Z

Content type: tutorial

Language: en

Sources: [Pranshu Raj](<https://devfeed.tech/sources/pranshu-raj-blog-on-backend-systems-performance-and-sidequests.md>)

Topics: [Go Language](<https://devfeed.tech/topics/go-language.md>), [Server-sent events (SSE)](<https://devfeed.tech/topics/server-sent-events-sse.md>), [Concurrency](<https://devfeed.tech/topics/concurrency.md>), [backpressure](<https://devfeed.tech/topics/backpressure.md>), [real-time](<https://devfeed.tech/topics/real-time.md>), [observability](<https://devfeed.tech/topics/observability.md>), [Redis](<https://devfeed.tech/topics/redis.md>), [Grafana](<https://devfeed.tech/topics/grafana.md>), [Prometheus](<https://devfeed.tech/topics/prometheus.md>)

Tags: [architecture](<https://devfeed.tech/tags/architecture.md>), [backpressure](<https://devfeed.tech/tags/backpressure.md>), [concurrency](<https://devfeed.tech/tags/concurrency.md>), [go](<https://devfeed.tech/tags/go.md>), [grafana](<https://devfeed.tech/tags/grafana.md>), [observability](<https://devfeed.tech/tags/observability.md>), [prometheus](<https://devfeed.tech/tags/prometheus.md>), [real-time](<https://devfeed.tech/tags/real-time.md>), [redis](<https://devfeed.tech/tags/redis.md>), [sse](<https://devfeed.tech/tags/sse.md>)

### AI overview

The article describes building a real-time leaderboard in Go that reached 28,232 concurrent SSE connections before exposing a broken broadcast design. It explains the fix using centralized polling, deduplication, fan-out, backpressure handling, and observability with Prometheus and Grafana.

### Source excerpt

A post on progressively getting my server to 28k SSE connections, finding a bug in my implementation of fan out using Go channels and the resulting mental model update.

[Next page](<https://devfeed.tech/tags/backpressure.md?cursor=WyIyMDI2LTA3LTIzVDAwOjAwOjAwKzAwOjAwIiwgImJjZWZiNjg2LTQ1ZTEtNGQ0ZS1iN2U2LWJhNDBmZDY0N2ExOCJd>)