# reliability

Published articles for reliability.

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

## How API Design Is Evolving for AI Agents, Security, Reliability, and Compliance

DevFeed: [How API Design Is Evolving for AI Agents, Security, Reliability, and Compliance](<https://devfeed.tech/articles/6-ways-traditional-api-design-has-changed-forever-34948.md>)

Original publisher: [Read original article](<https://nordicapis.com/6-ways-traditional-api-design-has-changed-forever/>)

Author: J Simpson

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

Content type: article

Language: en

Sources: [Nordic APIs](<https://devfeed.tech/sources/nordic-apis.md>)

Topics: [API](<https://devfeed.tech/topics/api.md>), [Architecture & Design](<https://devfeed.tech/topics/architecture-design.md>), [Artificial Intelligence](<https://devfeed.tech/topics/ai.md>), [reliability](<https://devfeed.tech/topics/reliability.md>), [Security](<https://devfeed.tech/topics/security.md>)

Tags: [agents](<https://devfeed.tech/tags/agents.md>), [ai-agents](<https://devfeed.tech/tags/ai-agents.md>), [api](<https://devfeed.tech/tags/api.md>), [api-architecture](<https://devfeed.tech/tags/api-architecture.md>), [api-as-a-product](<https://devfeed.tech/tags/api-as-a-product.md>), [api-design](<https://devfeed.tech/tags/api-design.md>), [api-discovery](<https://devfeed.tech/tags/api-discovery.md>), [api-security](<https://devfeed.tech/tags/api-security.md>), [architecture](<https://devfeed.tech/tags/architecture.md>), [authorization](<https://devfeed.tech/tags/authorization.md>), [blog](<https://devfeed.tech/tags/blog.md>), [mcp](<https://devfeed.tech/tags/mcp.md>), [microservices](<https://devfeed.tech/tags/microservices.md>), [rate-limiting](<https://devfeed.tech/tags/rate-limiting.md>), [reliability](<https://devfeed.tech/tags/reliability.md>), [security](<https://devfeed.tech/tags/security.md>)

### AI overview

This article examines six ways API design is evolving as APIs serve AI agents and other machine consumers, with implications for security, reliability, and regulatory compliance.

### Source excerpt

For over two decades, API design and architecture remained remarkably consistent. Perhaps it's the outsized influence of Roy Fielding's RESTful dissertation, but API designers have stuck to the principles of stateless architecture, resource-based endpoints, and HTTP commands to an impressive degree. That's all starting to change, now that we've radically recontextualized the way we use ...

## 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](<https://devfeed.tech/topics/reliability.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.

## AI Changed How Spotify Builds. What We Learned (and Fixed) About Quality at Higher Velocity

DevFeed: [AI Changed How Spotify Builds. What We Learned (and Fixed) About Quality at Higher Velocity](<https://devfeed.tech/articles/ai-changed-how-spotify-builds-what-we-learned-and-fixed-about-quality-at-higher-velocity-41282.md>)

Original publisher: [Read original article](<https://engineering.atspotify.com/2026/9/ai-changed-how-spotify-builds-what-we-learned-and-fixed-about-quality-at-higher-velocity/>)

Author: Spotify Engineering

Published: 2026-09-16T19:13:53Z

Content type: article

Language: en

Sources: [Spotify Engineering](<https://devfeed.tech/sources/spotify-engineering.md>), [Spotify Engineering Blog](<https://devfeed.tech/sources/spotify-engineering-blog.md>)

Topics: [Monitoring](<https://devfeed.tech/topics/monitoring.md>), [reliability](<https://devfeed.tech/topics/reliability.md>), [Microservices](<https://devfeed.tech/topics/microservices.md>), [Data pipelines](<https://devfeed.tech/topics/data-pipelines.md>), [Artificial Intelligence](<https://devfeed.tech/topics/ai.md>), [Job](<https://devfeed.tech/topics/job.md>)

Tags: [ai](<https://devfeed.tech/tags/ai.md>), [bug](<https://devfeed.tech/tags/bug.md>), [data-pipelines](<https://devfeed.tech/tags/data-pipelines.md>), [jobs](<https://devfeed.tech/tags/jobs.md>), [microservices](<https://devfeed.tech/tags/microservices.md>), [monitoring](<https://devfeed.tech/tags/monitoring.md>), [reliability](<https://devfeed.tech/tags/reliability.md>)

### AI overview

Spotify describes how rapid change, content-processing weaknesses, capacity limits, and a scheduling bug contributed to delays in publishing episodes. It reports adding end-to-end monitoring, fixing the scheduler, lowering batch-job priority, and increasing capacity.

### Source excerpt

Quality and reliability have always been a point of pride for Spotify. We run an extraordinarily complex... The post AI Changed How Spotify Builds. What We Learned (and Fixed) About Quality at Higher Velocity appeared first on Spotify Engineering.

## AI safety does not stop at the model

DevFeed: [AI safety does not stop at the model](<https://devfeed.tech/articles/ai-safety-does-not-stop-at-the-model-35705.md>)

Original publisher: [Read original article](<https://temporal.io/blog/ai-safety-does-not-stop-at-the-model>)

Author: Samar Abbas

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

Content type: opinion

Language: en

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

Topics: [ai safety](<https://devfeed.tech/topics/ai-safety.md>), [Agent Harness](<https://devfeed.tech/topics/agent-harness.md>), [reliability](<https://devfeed.tech/topics/reliability.md>), [retry](<https://devfeed.tech/topics/retry.md>), [Security](<https://devfeed.tech/topics/security.md>)

Tags: [agent](<https://devfeed.tech/tags/agent.md>), [agent-harness](<https://devfeed.tech/tags/agent-harness.md>), [ai](<https://devfeed.tech/tags/ai.md>), [reliability](<https://devfeed.tech/tags/reliability.md>), [retry](<https://devfeed.tech/tags/retry.md>), [safety](<https://devfeed.tech/tags/safety.md>), [security](<https://devfeed.tech/tags/security.md>), [temporal-voices](<https://devfeed.tech/tags/temporal-voices.md>)

### AI overview

The article argues that AI safety extends beyond model behavior to the application layer, where companies must control agent authority and enforce approvals, policies, and credential limits. It emphasizes that these controls must remain reliable through crashes, timeouts, and retries, and presents Temporal Agent Harness as an execution-layer control point around an agent SDK.

### Source excerpt

Auditing what an agent did is only half the job. Companies also have to control what agents may do, and make those limits hold when systems fail.

## A Backward NTP Clock Step Delayed a Python Scheduler's Measurements by Nine Days

DevFeed: [A Backward NTP Clock Step Delayed a Python Scheduler's Measurements by Nine Days](<https://devfeed.tech/articles/the-ntp-clock-jump-that-made-the-scheduler-skip-a-week-of-measurements-34099.md>)

Original publisher: [Read original article](<https://philipptheserver.com/posts/clock-jump-scheduler/>)

Author: Philipp Lehmann (philipp.lehmann@gruppe.ai)

Published: 2026-09-14T07:00:00Z

Content type: tutorial

Language: en

Sources: [Philipp Lehmann](<https://devfeed.tech/sources/philipp-lehmann.md>)

Topics: [Python](<https://devfeed.tech/topics/python.md>), [Linux](<https://devfeed.tech/topics/linux.md>), [systemd](<https://devfeed.tech/topics/systemd.md>), [Single Board Computer](<https://devfeed.tech/topics/single-board-computer.md>)

Tags: [embedded](<https://devfeed.tech/tags/embedded.md>), [linux](<https://devfeed.tech/tags/linux.md>), [ntp](<https://devfeed.tech/tags/ntp.md>), [python](<https://devfeed.tech/tags/python.md>), [reliability](<https://devfeed.tech/tags/reliability.md>), [scheduler](<https://devfeed.tech/tags/scheduler.md>), [single-board-computer](<https://devfeed.tech/tags/single-board-computer.md>), [systemd](<https://devfeed.tech/tags/systemd.md>), [time](<https://devfeed.tech/tags/time.md>), [wall-clock-time](<https://devfeed.tech/tags/wall-clock-time.md>)

### AI overview

A Python scheduler on an embedded Linux device silently stopped running after NTP corrected the system clock backward by about nine days. Because it used wall-clock time to measure elapsed time, the scheduler waited roughly nine days before running again. The article explains why a monotonic clock is the appropriate fix and mentions testing with an injected clock jump.

### Source excerpt

time.time() vs time.monotonic() in a Python scheduler: a backwards NTP step delayed runs by nine days. Monotonic durations and a jump-injecting test.

## Temporal raises $550M at a $12.55B valuation as demand grows for reliable AI infrastructure

DevFeed: [Temporal raises $550M at a $12.55B valuation as demand grows for reliable AI infrastructure](<https://devfeed.tech/articles/temporal-raises-550m-at-a-12-55b-valuation-as-demand-grows-for-reliable-ai-infrastructure-36026.md>)

Original publisher: [Read original article](<https://temporal.io/blog/temporal-raises-usd550m-series-e-at-usd12-55b-valuation-ai>)

Author: Allanah Hughes

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

Content type: release

Language: en

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

Topics: [AI Infrastructure](<https://devfeed.tech/topics/ai-infrastructure.md>), [reliability](<https://devfeed.tech/topics/reliability.md>), [Orchestration](<https://devfeed.tech/topics/orchestration.md>), [AI Platform](<https://devfeed.tech/topics/ai-platform.md>)

Tags: [agents](<https://devfeed.tech/tags/agents.md>), [ai](<https://devfeed.tech/tags/ai.md>), [ai-infrastructure](<https://devfeed.tech/tags/ai-infrastructure.md>), [announcements](<https://devfeed.tech/tags/announcements.md>), [funding](<https://devfeed.tech/tags/funding.md>), [infrastructure](<https://devfeed.tech/tags/infrastructure.md>), [orchestration](<https://devfeed.tech/tags/orchestration.md>), [outage](<https://devfeed.tech/tags/outage.md>), [reliability](<https://devfeed.tech/tags/reliability.md>), [series](<https://devfeed.tech/tags/series.md>), [systems](<https://devfeed.tech/tags/systems.md>)

### AI overview

Temporal announces a $550 million Series E funding round at a $12.55 billion valuation. The company says the funding will support reliable infrastructure for long-running AI agents and applications, including orchestration and recovery across systems.

### Source excerpt

AI is raising the bar for reliability. See why Temporal's $550M Series E, backed by Lightspeed and others, is built to meet that demand.

## A letter from Samar: a year of achievements, and what's next for us

DevFeed: [A letter from Samar: a year of achievements, and what's next for us](<https://devfeed.tech/articles/a-letter-from-samar-a-year-of-achievements-and-what-s-next-for-us-36034.md>)

Original publisher: [Read original article](<https://temporal.io/blog/temporal-series-e-letter-from-ceo-samar-abbas>)

Author: Samar Abbas

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

Content type: opinion

Language: en

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

Topics: [reliability](<https://devfeed.tech/topics/reliability.md>), [Artificial Intelligence](<https://devfeed.tech/topics/ai.md>), [OpenAI](<https://devfeed.tech/topics/openai.md>)

Tags: [agents](<https://devfeed.tech/tags/agents.md>), [ai-agents](<https://devfeed.tech/tags/ai-agents.md>), [growth](<https://devfeed.tech/tags/growth.md>), [openai](<https://devfeed.tech/tags/openai.md>), [reliability](<https://devfeed.tech/tags/reliability.md>), [temporal](<https://devfeed.tech/tags/temporal.md>), [temporal-voices](<https://devfeed.tech/tags/temporal-voices.md>)

### AI overview

Temporal CEO Samar Abbas reviews a year of company growth, leadership changes, the Series E raise, platform usage, and customer examples. He argues that reliable infrastructure and Durable Execution remain important as AI increases application complexity and expectations.

### Source excerpt

Temporal CEO Samar Abbas on a year of record growth, the Series E raise, and why Durable Execution is now core infrastructure for reliable AI agents.

## Every service needs an owner

DevFeed: [Every service needs an owner](<https://devfeed.tech/articles/every-service-needs-an-owner-34011.md>)

Original publisher: [Read original article](<https://sridharrajarao.com/blog/every-service-needs-an-owner/>)

Author: Sridhar Rajarao

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

Content type: article

Language: en

Sources: [Sridhar Rajarao](<https://devfeed.tech/sources/sridhar-rajarao.md>)

Topics: [systems](<https://devfeed.tech/topics/systems.md>), [incident](<https://devfeed.tech/topics/incident.md>)

Tags: [catalog](<https://devfeed.tech/tags/catalog.md>), [customer](<https://devfeed.tech/tags/customer.md>), [incident](<https://devfeed.tech/tags/incident.md>), [on-call](<https://devfeed.tech/tags/on-call.md>), [ownership](<https://devfeed.tech/tags/ownership.md>), [platform-engineering](<https://devfeed.tech/tags/platform-engineering.md>), [production](<https://devfeed.tech/tags/production.md>), [reliability](<https://devfeed.tech/tags/reliability.md>), [service](<https://devfeed.tech/tags/service.md>), [service-catalog](<https://devfeed.tech/tags/service-catalog.md>), [sre](<https://devfeed.tech/tags/sre.md>), [startups](<https://devfeed.tech/tags/startups.md>), [team](<https://devfeed.tech/tags/team.md>)

### AI overview

The article argues that growing organizations need a focused service catalog to make production ownership visible. It recommends recording each service's customer outcome, owning team, current on-call contact, deployment path, health dashboard, runbook, and dependencies, and maintaining those records as part of engineering work.

### Source excerpt

A useful service catalog is not an inventory project. It is a public record of who owns a customer outcome when the system is healthy and when it fails.

## fsGroupChangePolicy: OnRootMismatch and the setgid Invariant That Makes It Sound

DevFeed: [fsGroupChangePolicy: OnRootMismatch and the setgid Invariant That Makes It Sound](<https://devfeed.tech/articles/fsgroupchangepolicy-onrootmismatch-and-the-setgid-invariant-that-makes-it-sound-34103.md>)

Original publisher: [Read original article](<https://philipptheserver.com/posts/fsgroup-change-policy-root-mismatch/>)

Author: Philipp Lehmann (philipp.lehmann@gruppe.ai)

Published: 2026-09-11T07:00:00Z

Content type: tutorial

Language: en

Sources: [Philipp Lehmann](<https://devfeed.tech/sources/philipp-lehmann.md>)

Topics: [container](<https://devfeed.tech/topics/container.md>), [mount](<https://devfeed.tech/topics/mount.md>), [Security](<https://devfeed.tech/topics/security.md>), [Process](<https://devfeed.tech/topics/process.md>)

Tags: [container](<https://devfeed.tech/tags/container.md>), [container-image](<https://devfeed.tech/tags/container-image.md>), [kubernetes](<https://devfeed.tech/tags/kubernetes.md>), [mount](<https://devfeed.tech/tags/mount.md>), [network](<https://devfeed.tech/tags/network.md>), [performance](<https://devfeed.tech/tags/performance.md>), [reliability](<https://devfeed.tech/tags/reliability.md>), [security](<https://devfeed.tech/tags/security.md>), [stateful](<https://devfeed.tech/tags/stateful.md>), [storage](<https://devfeed.tech/tags/storage.md>), [waiting](<https://devfeed.tech/tags/waiting.md>)

### AI overview

This article explains why a stateful pod can remain in ContainerCreating for fifteen minutes when fsGroup triggers a recursive chown across a large network-backed volume. It describes how fsGroupChangePolicy: OnRootMismatch can skip the recursive walk when the volume root group already matches, and discusses the setgid invariant that supports this behavior.

### Source excerpt

Pod stuck in ContainerCreating from fsGroup recursive chown: fsGroupChangePolicy: OnRootMismatch, and why the setgid bit on the volume root makes it safe.

## Negative caching protects databases from repeated lookups for nonexistent keys

DevFeed: [Negative caching protects databases from repeated lookups for nonexistent keys](<https://devfeed.tech/articles/negative-caching-the-misses-cost-more-than-the-hits-39602.md>)

Original publisher: [Read original article](<https://ankit-rana.com/logs/50-negative-caching-misses-cost-more/>)

Author: hello@ankit-rana.com

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

Content type: tutorial

Language: en

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

Topics: [Caching](<https://devfeed.tech/topics/caching.md>), [Cache](<https://devfeed.tech/topics/cache.md>), [Database](<https://devfeed.tech/topics/database.md>), [Security](<https://devfeed.tech/topics/security.md>), [Latency](<https://devfeed.tech/topics/latency.md>)

Tags: [cache](<https://devfeed.tech/tags/cache.md>), [cache-penetration](<https://devfeed.tech/tags/cache-penetration.md>), [caching](<https://devfeed.tech/tags/caching.md>), [database](<https://devfeed.tech/tags/database.md>), [negative-caching](<https://devfeed.tech/tags/negative-caching.md>), [protection](<https://devfeed.tech/tags/protection.md>), [redis](<https://devfeed.tech/tags/redis.md>), [reliability](<https://devfeed.tech/tags/reliability.md>), [security](<https://devfeed.tech/tags/security.md>), [ttl](<https://devfeed.tech/tags/ttl.md>)

### AI overview

Negative caching prevents repeated database queries for nonexistent keys by storing a distinguishable marker for negative results. The article explains how partner integrations, scrapers, stale clients, migrations, or attackers can exploit this gap and recommends using a shorter TTL for negative entries.

### Source excerpt

A cache that stores only found values gives you no protection against lookups for things that do not exist, and a miss on a nonexistent key costs the full origin query every single time. If the key is user supplied, an attacker can generate unlimited unique misses and bypass the cache entirely, which is cache penetration. Caching the negative result fixes it, with a shorter TTL than positive entries because a value appearing is a much more likely event than one disappearing.

## kube-proxy in iptables Mode and Native nftables Rules in the Forward Chain

DevFeed: [kube-proxy in iptables Mode and Native nftables Rules in the Forward Chain](<https://devfeed.tech/articles/kube-proxy-in-iptables-mode-and-native-nftables-rules-in-the-forward-chain-34106.md>)

Original publisher: [Read original article](<https://philipptheserver.com/posts/kube-proxy-native-nftables/>)

Author: Philipp Lehmann (philipp.lehmann@gruppe.ai)

Published: 2026-09-08T07:00:00Z

Content type: article

Language: en

Sources: [Philipp Lehmann](<https://devfeed.tech/sources/philipp-lehmann.md>)

Topics: [proxy](<https://devfeed.tech/topics/proxy.md>), [Kernel](<https://devfeed.tech/topics/kernel.md>), [Virtual Private Network](<https://devfeed.tech/topics/vpn.md>)

Tags: [firewall](<https://devfeed.tech/tags/firewall.md>), [handle](<https://devfeed.tech/tags/handle.md>), [ip](<https://devfeed.tech/tags/ip.md>), [kernel](<https://devfeed.tech/tags/kernel.md>), [kubernetes](<https://devfeed.tech/tags/kubernetes.md>), [linux](<https://devfeed.tech/tags/linux.md>), [networking](<https://devfeed.tech/tags/networking.md>), [proxy](<https://devfeed.tech/tags/proxy.md>), [reliability](<https://devfeed.tech/tags/reliability.md>), [vpn](<https://devfeed.tech/tags/vpn.md>)

### AI overview

The article explains how native nftables rules added by a WireGuard-based mesh agent to the FORWARD chain can cause kube-proxy in iptables mode to abort synchronization silently, leaving service endpoints stale. It describes removing the conflicting rules by handle.

### Source excerpt

kube-proxy iptables-nft sync silently aborts on native nftables rules a mesh agent adds to the FORWARD chain. Fix: nft delete rule by handle, ip and ip6.

## How Fixed Intervals Synchronize Distributed Clients and How Jitter Helps

DevFeed: [How Fixed Intervals Synchronize Distributed Clients and How Jitter Helps](<https://devfeed.tech/articles/jitter-is-the-cheapest-reliability-fix-you-are-not-using-39601.md>)

Original publisher: [Read original article](<https://ankit-rana.com/logs/49-jitter-synchronised-clients/>)

Author: hello@ankit-rana.com

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

Content type: opinion

Language: en

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

Topics: [reliability](<https://devfeed.tech/topics/reliability.md>), [distributed-systems](<https://devfeed.tech/topics/distributed-systems.md>), [systems](<https://devfeed.tech/topics/systems.md>), [Network](<https://devfeed.tech/topics/network.md>), [Cache](<https://devfeed.tech/topics/cache.md>), [Redis](<https://devfeed.tech/topics/redis.md>)

Tags: [aws](<https://devfeed.tech/tags/aws.md>), [cache](<https://devfeed.tech/tags/cache.md>), [code](<https://devfeed.tech/tags/code.md>), [distributed-systems](<https://devfeed.tech/tags/distributed-systems.md>), [jitter](<https://devfeed.tech/tags/jitter.md>), [network](<https://devfeed.tech/tags/network.md>), [reliability](<https://devfeed.tech/tags/reliability.md>), [resilience](<https://devfeed.tech/tags/resilience.md>), [retries](<https://devfeed.tech/tags/retries.md>), [thundering-herd](<https://devfeed.tech/tags/thundering-herd.md>)

### AI overview

Fixed retry intervals, TTLs, restarts, reconnects, and other recurring events can cause independent clients in distributed systems to synchronize, producing repeated load spikes. Adding randomness, or jitter, helps break that alignment; the article cites AWS measurements indicating that full jitter improves total work and completion time under contention.

### Source excerpt

Distributed systems synchronise themselves without being told to: every client that retries on a fixed interval, restarts after a deploy, or reconnects after a network blip ends up firing at the same moment as every other client. The resulting spike is a self-inflicted denial of service that no single component is responsible for. Adding randomness to any repeating interval breaks the alignment, and it is usually one line of code against a failure mode that otherwise requires capacity you never needed.

## Cache stampede: how one expired key takes down the database

DevFeed: [Cache stampede: how one expired key takes down the database](<https://devfeed.tech/articles/cache-stampede-how-one-expired-key-takes-down-the-database-39600.md>)

Original publisher: [Read original article](<https://ankit-rana.com/logs/48-cache-stampede-expired-key/>)

Author: hello@ankit-rana.com

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

Content type: tutorial

Language: en

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

Topics: [Cache](<https://devfeed.tech/topics/cache.md>), [Caching](<https://devfeed.tech/topics/caching.md>), [Database](<https://devfeed.tech/topics/database.md>), [consistent hashing](<https://devfeed.tech/topics/consistent-hashing.md>), [Redis](<https://devfeed.tech/topics/redis.md>)

Tags: [cache-stampede](<https://devfeed.tech/tags/cache-stampede.md>), [caching](<https://devfeed.tech/tags/caching.md>), [connection-pool](<https://devfeed.tech/tags/connection-pool.md>), [consistent-hashing](<https://devfeed.tech/tags/consistent-hashing.md>), [distributed-systems](<https://devfeed.tech/tags/distributed-systems.md>), [jitter](<https://devfeed.tech/tags/jitter.md>), [query](<https://devfeed.tech/tags/query.md>), [redis](<https://devfeed.tech/tags/redis.md>), [reliability](<https://devfeed.tech/tags/reliability.md>), [thundering-herd](<https://devfeed.tech/tags/thundering-herd.md>), [traffic](<https://devfeed.tech/tags/traffic.md>), [ttl](<https://devfeed.tech/tags/ttl.md>)

### AI overview

This article explains how a cache stampede occurs when a hot key expires and many requests simultaneously recompute the same value against the database. It recommends TTL jitter to prevent synchronized expirations and request coalescing so only one caller recomputes while others wait or serve stale data. It also discusses cache warming and consistent hashing for broader cache-failure scenarios.

### Source excerpt

A cache TTL is a scheduled simultaneous failure: every request being served from one key misses at the same instant and goes to the origin together. If the recompute takes two seconds, every request arriving during those two seconds also misses, so the pileup grows faster than it drains. Jitter on the TTL stops keys expiring in lockstep, and request coalescing so only one caller recomputes while the rest wait or serve stale is what stops a single expensive key from saturating the database.

## AI data centers: the five hard problems money cannot buy away

DevFeed: [AI data centers: the five hard problems money cannot buy away](<https://devfeed.tech/articles/ai-data-centers-the-five-hard-problems-money-cannot-buy-away-34007.md>)

Original publisher: [Read original article](<https://sridharrajarao.com/blog/ai-datacenter-buildout-five-issues/>)

Author: Sridhar Rajarao

Published: 2026-08-30T00:00:00Z

Content type: article

Language: en

Sources: [Sridhar Rajarao](<https://devfeed.tech/sources/sridhar-rajarao.md>)

Topics: [Artificial Intelligence](<https://devfeed.tech/topics/ai.md>), [data centers](<https://devfeed.tech/topics/data-centers.md>), [Hardware](<https://devfeed.tech/topics/hardware.md>), [systems](<https://devfeed.tech/topics/systems.md>)

Tags: [ai](<https://devfeed.tech/tags/ai.md>), [capacity](<https://devfeed.tech/tags/capacity.md>), [compute](<https://devfeed.tech/tags/compute.md>), [data-centers](<https://devfeed.tech/tags/data-centers.md>), [datacenters](<https://devfeed.tech/tags/datacenters.md>), [hardware](<https://devfeed.tech/tags/hardware.md>), [heat](<https://devfeed.tech/tags/heat.md>), [infrastructure](<https://devfeed.tech/tags/infrastructure.md>), [power](<https://devfeed.tech/tags/power.md>), [reliability](<https://devfeed.tech/tags/reliability.md>)

### AI overview

The article argues that AI data-center expansion is constrained by the simultaneous need to secure power, grid connections, cooling and water strategies, equipment, skilled workers, permits, and productive compute. It discusses five industry challenges, with the supplied text covering power constraints and the physical and water implications of liquid cooling.

### Source excerpt

The AI buildout is not mainly a real-estate problem. It is a race to integrate power, cooling, equipment, permits, and useful compute at the same time.

## Why Senior Leaders Should Attend Post-Incident Reviews for Major Cloud Incidents

DevFeed: [Why Senior Leaders Should Attend Post-Incident Reviews for Major Cloud Incidents](<https://devfeed.tech/articles/should-senior-leadership-attend-a-pir-34023.md>)

Original publisher: [Read original article](<https://sridharrajarao.com/blog/should-senior-leadership-attend-pir/>)

Author: Sridhar Rajarao

Published: 2026-08-29T00:00:00Z

Content type: opinion

Language: en

Sources: [Sridhar Rajarao](<https://devfeed.tech/sources/sridhar-rajarao.md>)

Topics: [incident](<https://devfeed.tech/topics/incident.md>), [Cloud](<https://devfeed.tech/topics/cloud.md>), [control-plane](<https://devfeed.tech/topics/control-plane.md>), [Deployment](<https://devfeed.tech/topics/deployment.md>)

Tags: [cloud](<https://devfeed.tech/tags/cloud.md>), [control-plane](<https://devfeed.tech/tags/control-plane.md>), [customers](<https://devfeed.tech/tags/customers.md>), [deploy](<https://devfeed.tech/tags/deploy.md>), [incident](<https://devfeed.tech/tags/incident.md>), [incident-management](<https://devfeed.tech/tags/incident-management.md>), [leadership](<https://devfeed.tech/tags/leadership.md>), [major](<https://devfeed.tech/tags/major.md>), [operations](<https://devfeed.tech/tags/operations.md>), [post](<https://devfeed.tech/tags/post.md>), [postmortems](<https://devfeed.tech/tags/postmortems.md>), [reliability](<https://devfeed.tech/tags/reliability.md>), [review](<https://devfeed.tech/tags/review.md>), [service](<https://devfeed.tech/tags/service.md>)

### AI overview

The article argues that senior leaders should attend Post Incident Reviews for major cloud incidents because failures can affect many customers and teams. Leadership helps approve cross-team changes, resolve trade-offs, and ensure corrective actions are completed.

### Source excerpt

For major incidents, a Post Incident Review is not an operations meeting. It is where leaders remove the blockers that keep the service from becoming safer.

## Why GitHub feels less reliable lately

DevFeed: [Why GitHub feels less reliable lately](<https://devfeed.tech/articles/why-github-feels-less-reliable-lately-34026.md>)

Original publisher: [Read original article](<https://sridharrajarao.com/blog/why-github-feels-less-reliable/>)

Author: Sridhar Rajarao

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

Content type: opinion

Language: en

Sources: [Sridhar Rajarao](<https://devfeed.tech/sources/sridhar-rajarao.md>)

Topics: [GitHub](<https://devfeed.tech/topics/github.md>), [incident](<https://devfeed.tech/topics/incident.md>), [migration](<https://devfeed.tech/topics/migration.md>), [systems](<https://devfeed.tech/topics/systems.md>), [Azure](<https://devfeed.tech/topics/azure.md>), [GitHub Actions](<https://devfeed.tech/topics/github-actions.md>), [pull-requests](<https://devfeed.tech/topics/pull-requests.md>)

Tags: [autoscaling](<https://devfeed.tech/tags/autoscaling.md>), [capacity](<https://devfeed.tech/tags/capacity.md>), [concurrency](<https://devfeed.tech/tags/concurrency.md>), [data-centers](<https://devfeed.tech/tags/data-centers.md>), [deployment](<https://devfeed.tech/tags/deployment.md>), [github](<https://devfeed.tech/tags/github.md>), [incident](<https://devfeed.tech/tags/incident.md>), [incident-management](<https://devfeed.tech/tags/incident-management.md>), [istio](<https://devfeed.tech/tags/istio.md>), [reliability](<https://devfeed.tech/tags/reliability.md>), [request](<https://devfeed.tech/tags/request.md>), [resilience](<https://devfeed.tech/tags/resilience.md>), [sre](<https://devfeed.tech/tags/sre.md>), [transformation](<https://devfeed.tech/tags/transformation.md>)

### AI overview

The article argues that GitHub's recent reliability problems reflect the difficult middle of a major infrastructure transformation. It connects incidents to migration complexity, unsafe automation, configuration mistakes, capacity and concurrency weaknesses, database migration errors, and autoscaling problems.

### Source excerpt

GitHub is not having one outage problem. Its recent incident reports show the difficult middle of a platform transformation.

## How MongoDB Atlas and Temporal support reliable production RAG and AI agents

DevFeed: [How MongoDB Atlas and Temporal support reliable production RAG and AI agents](<https://devfeed.tech/articles/durable-rag-and-agents-mongodb-and-temporal-doing-it-better-together-35920.md>)

Original publisher: [Read original article](<https://temporal.io/blog/mongodb-temporal-partnership-rag-agents>)

Author: Suresh Ramappa

Published: 2026-08-13T00:00:00Z

Content type: opinion

Language: en

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

Topics: [MongoDB](<https://devfeed.tech/topics/mongodb.md>), [Retrieval Augmented Generation (RAG)](<https://devfeed.tech/topics/retrieval-augmented-generation-rag.md>), [AI Infrastructure](<https://devfeed.tech/topics/ai-infrastructure.md>), [Artificial Intelligence](<https://devfeed.tech/topics/ai.md>), [reliability](<https://devfeed.tech/topics/reliability.md>)

Tags: [agentic](<https://devfeed.tech/tags/agentic.md>), [agents](<https://devfeed.tech/tags/agents.md>), [ai](<https://devfeed.tech/tags/ai.md>), [ai-infrastructure](<https://devfeed.tech/tags/ai-infrastructure.md>), [api](<https://devfeed.tech/tags/api.md>), [data](<https://devfeed.tech/tags/data.md>), [embeddings](<https://devfeed.tech/tags/embeddings.md>), [long-running](<https://devfeed.tech/tags/long-running.md>), [mongodb](<https://devfeed.tech/tags/mongodb.md>), [outages](<https://devfeed.tech/tags/outages.md>), [pipelines](<https://devfeed.tech/tags/pipelines.md>), [production](<https://devfeed.tech/tags/production.md>), [rag](<https://devfeed.tech/tags/rag.md>), [recovery](<https://devfeed.tech/tags/recovery.md>), [reliability](<https://devfeed.tech/tags/reliability.md>), [retries](<https://devfeed.tech/tags/retries.md>), [retrieval](<https://devfeed.tech/tags/retrieval.md>), [temporal-voices](<https://devfeed.tech/tags/temporal-voices.md>)

### AI overview

The article argues that MongoDB Atlas and Temporal address different reliability needs in production RAG and AI agent systems. Atlas provides operational data, embeddings, vector search, and agent memory in one platform, while Temporal provides durable execution for crash recovery, retries, and long-running ingestion and agent workflows.

### Source excerpt

Why MongoDB Atlas and Temporal are better together for AI: one data platform, one durable execution layer, for RAG and agents in prod.

## Using observability to verify TLS certificate rotation in production

DevFeed: [Using observability to verify TLS certificate rotation in production](<https://devfeed.tech/articles/your-tls-rotation-is-not-reliable-until-production-proves-it-34025.md>)

Original publisher: [Read original article](<https://sridharrajarao.com/blog/tls-rotation-observability/>)

Author: Sridhar Rajarao

Published: 2026-08-13T00:00:00Z

Content type: article

Language: en

Sources: [Sridhar Rajarao](<https://devfeed.tech/sources/sridhar-rajarao.md>)

Topics: [TLS (Transport Layer Security)](<https://devfeed.tech/topics/tls.md>), [observability](<https://devfeed.tech/topics/observability.md>), [TLS handshake](<https://devfeed.tech/topics/tls-handshake.md>), [Automation](<https://devfeed.tech/topics/automation.md>), [nginx](<https://devfeed.tech/topics/nginx.md>), [Kubernetes](<https://devfeed.tech/topics/kubernetes.md>)

Tags: [automation](<https://devfeed.tech/tags/automation.md>), [nginx](<https://devfeed.tech/tags/nginx.md>), [observability](<https://devfeed.tech/tags/observability.md>), [reliability](<https://devfeed.tech/tags/reliability.md>), [sre](<https://devfeed.tech/tags/sre.md>), [tls](<https://devfeed.tech/tags/tls.md>), [tls-handshake](<https://devfeed.tech/tags/tls-handshake.md>)

### AI overview

The article explains that automating certificate renewal does not prove that production endpoints serve the new certificate. It recommends externally probing customer-facing endpoints and measuring certificate details and real TLS handshakes across proxies, regions, ingress controllers, CDNs, gateways, and other endpoints.

### Source excerpt

Automation renews a certificate. Observability proves every endpoint is serving it and customers can complete a TLS handshake.

## The Pulse: Quitting Spotify Podcasts over reliability

DevFeed: [The Pulse: Quitting Spotify Podcasts over reliability](<https://devfeed.tech/articles/the-pulse-quitting-spotify-podcasts-over-reliability-40927.md>)

Original publisher: [Read original article](<https://blog.pragmaticengineer.com/the-pulse-quitting-spotify-podcasts-over-reliability/>)

Author: Ivan Klaric

Published: 2026-07-30T15:51:38Z

Content type: opinion

Language: en

Sources: [The Pragmatic Engineer](<https://devfeed.tech/sources/the-pragmatic-engineer-2.md>)

Topics: [Spotify](<https://devfeed.tech/topics/spotify.md>), [reliability](<https://devfeed.tech/topics/reliability.md>), [Streaming](<https://devfeed.tech/topics/streaming.md>), [RSS Feed](<https://devfeed.tech/topics/rss-feed.md>)

Tags: [article](<https://devfeed.tech/tags/article.md>), [reliability](<https://devfeed.tech/tags/reliability.md>), [rss](<https://devfeed.tech/tags/rss.md>), [streaming](<https://devfeed.tech/tags/streaming.md>)

### AI overview

The author stopped publishing video podcast episodes on Spotify after encountering repeated reliability problems processing video episodes. Audio episodes remain available through Spotify's RSS feed, while video episodes are published on YouTube.

### Source excerpt

Spotify's podcast platform has become chronically unreliable since the company's leadership started boasting about AI adoption. Competitors haven't had similar issues, so I offboarded from Spotify.

## ITIL vs SRE: why the big clouds went their own way

DevFeed: [ITIL vs SRE: why the big clouds went their own way](<https://devfeed.tech/articles/itil-vs-sre-why-the-big-clouds-went-their-own-way-34015.md>)

Original publisher: [Read original article](<https://sridharrajarao.com/blog/itil-vs-sre/>)

Author: Sridhar Rajarao

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

Content type: opinion

Language: en

Sources: [Sridhar Rajarao](<https://devfeed.tech/sources/sridhar-rajarao.md>)

Topics: [SRE](<https://devfeed.tech/topics/sre.md>), [site-reliability-engineering](<https://devfeed.tech/topics/site-reliability-engineering.md>), [Development](<https://devfeed.tech/topics/development.md>), [Terraform](<https://devfeed.tech/topics/terraform.md>), [pulumi](<https://devfeed.tech/topics/pulumi.md>), [Availability](<https://devfeed.tech/topics/availability.md>), [feature flags](<https://devfeed.tech/topics/feature-flags.md>), [incident](<https://devfeed.tech/topics/incident.md>)

Tags: [automated](<https://devfeed.tech/tags/automated.md>), [aws](<https://devfeed.tech/tags/aws.md>), [azure](<https://devfeed.tech/tags/azure.md>), [cloud](<https://devfeed.tech/tags/cloud.md>), [feature-flags](<https://devfeed.tech/tags/feature-flags.md>), [gcp](<https://devfeed.tech/tags/gcp.md>), [human-review](<https://devfeed.tech/tags/human-review.md>), [hyperscaler](<https://devfeed.tech/tags/hyperscaler.md>), [incident](<https://devfeed.tech/tags/incident.md>), [incident-management](<https://devfeed.tech/tags/incident-management.md>), [infrastructure-as-code](<https://devfeed.tech/tags/infrastructure-as-code.md>), [itil](<https://devfeed.tech/tags/itil.md>), [on-call](<https://devfeed.tech/tags/on-call.md>), [postmortems](<https://devfeed.tech/tags/postmortems.md>), [pulumi](<https://devfeed.tech/tags/pulumi.md>), [release](<https://devfeed.tech/tags/release.md>), [reliability](<https://devfeed.tech/tags/reliability.md>), [service-catalog](<https://devfeed.tech/tags/service-catalog.md>), [sre](<https://devfeed.tech/tags/sre.md>), [terraform](<https://devfeed.tech/tags/terraform.md>)

### AI overview

This opinion article compares ITIL practices with SRE operations at hyperscaler scale. It argues that human change boards, single production instances, developer-to-operations handoffs, documentation-first configuration management, and weekly release windows do not fit environments serving millions of external customers. It describes automated approvals, gradual deployments, service-team ownership, infrastructure as code, continuous release, error budgets, SLOs, and blameless postmortems as alternatives.

### Source excerpt

The big clouds don't run ITIL. Five assumptions ITIL makes that break at hyperscaler scale, and what AWS, Azure, GCP, and OCI use instead.

## Control Reliability Engineering (CRE): Applying SRE Principles to Cybersecurity Controls

DevFeed: [Control Reliability Engineering (CRE): Applying SRE Principles to Cybersecurity Controls](<https://devfeed.tech/articles/control-reliability-engineering-cre-applying-sre-principles-to-cybersecurity-controls-39486.md>)

Original publisher: [Read original article](<https://www.philvenables.com/post/control-reliability-engineering-cre-applying-sre-principles-to-cybersecurity-controls>)

Author: phil7672

Published: 2026-07-25T05:52:21Z

Content type: article

Language: en

Sources: [Risk and Cyber](<https://devfeed.tech/sources/risk-and-cyber.md>)

Topics: [Cybersecurity](<https://devfeed.tech/topics/cybersecurity.md>), [SRE](<https://devfeed.tech/topics/sre.md>), [Monitoring](<https://devfeed.tech/topics/monitoring.md>), [reliability](<https://devfeed.tech/topics/reliability.md>), [plotting](<https://devfeed.tech/topics/plotting.md>)

Tags: [benchmarking](<https://devfeed.tech/tags/benchmarking.md>), [cybersecurity](<https://devfeed.tech/tags/cybersecurity.md>), [leadership](<https://devfeed.tech/tags/leadership.md>), [monitoring](<https://devfeed.tech/tags/monitoring.md>), [reliability](<https://devfeed.tech/tags/reliability.md>), [reliability-engineering](<https://devfeed.tech/tags/reliability-engineering.md>), [risk](<https://devfeed.tech/tags/risk.md>), [sre](<https://devfeed.tech/tags/sre.md>), [technology](<https://devfeed.tech/tags/technology.md>)

### AI overview

This article applies SRE principles to cybersecurity controls, arguing that control effectiveness matters more than input-focused budget comparisons. It highlights continuous control monitoring to detect controls that are broken, misconfigured, or incomplete when needed.

### Source excerpt

Security breaches are often not the result of awesome attacker capabilities or the sudden emergence of sophisticated zero-day exploits. Instead, what we usually find are the controls designed to stop the attack were believed to be operational but were actually broken or misconfigured at the moment when they were needed. Sometimes they were never fully in place to meet the security team's original intent. So, continuous control monitoring is needed to counter the natural decay that occurs to...

## Session revocations at scale

DevFeed: [Session revocations at scale](<https://devfeed.tech/articles/session-revocations-at-scale-37933.md>)

Original publisher: [Read original article](<https://www.canva.dev/blog/engineering/session-revocations-at-scale/>)

Author: Llew Vallis

Published: 2026-07-22T00:00:01Z

Content type: article

Language: en

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

Topics: [sessions](<https://devfeed.tech/topics/sessions.md>), [Cookies](<https://devfeed.tech/topics/cookies.md>), [Authorization](<https://devfeed.tech/topics/authorization.md>), [Caching](<https://devfeed.tech/topics/caching.md>), [MySQL](<https://devfeed.tech/topics/mysql.md>), [scaling](<https://devfeed.tech/topics/scaling.md>), [gateway](<https://devfeed.tech/topics/gateway.md>), [Redis](<https://devfeed.tech/topics/redis.md>), [reliability](<https://devfeed.tech/topics/reliability.md>)

Tags: [backend](<https://devfeed.tech/tags/backend.md>), [caching](<https://devfeed.tech/tags/caching.md>), [cookies](<https://devfeed.tech/tags/cookies.md>), [gateway](<https://devfeed.tech/tags/gateway.md>), [mysql](<https://devfeed.tech/tags/mysql.md>), [permissions](<https://devfeed.tech/tags/permissions.md>), [redis](<https://devfeed.tech/tags/redis.md>), [reliability](<https://devfeed.tech/tags/reliability.md>), [scaling](<https://devfeed.tech/tags/scaling.md>), [security](<https://devfeed.tech/tags/security.md>), [sessions](<https://devfeed.tech/tags/sessions.md>)

### AI overview

Canva describes how it manages session revocations for hundreds of millions of users. The system keeps revocations in memory for fast gateway checks, while MySQL handles refresh-time lookups; the article explains how loading the cache during deployments created database load and discusses evaluating Redis as a caching solution.

### Source excerpt

How Canva keeps hundreds of millions of user sessions fast and secure

## Why Temporal is the front-of-shirt sponsor for Crystal Palace

DevFeed: [Why Temporal is the front-of-shirt sponsor for Crystal Palace](<https://devfeed.tech/articles/why-temporal-is-the-front-of-shirt-sponsor-for-crystal-palace-36110.md>)

Original publisher: [Read original article](<https://temporal.io/blog/why-temporal-is-front-of-shirt-sponsor-crystal-palace>)

Author: Samar Abbas

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

Content type: opinion

Language: en

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

Topics: [Software](<https://devfeed.tech/topics/software.md>), [reliability](<https://devfeed.tech/topics/reliability.md>), [Job](<https://devfeed.tech/topics/job.md>), [OpenAI](<https://devfeed.tech/topics/openai.md>)

Tags: [announcements](<https://devfeed.tech/tags/announcements.md>), [communities](<https://devfeed.tech/tags/communities.md>), [company](<https://devfeed.tech/tags/company.md>), [developer](<https://devfeed.tech/tags/developer.md>), [enterprise-technology](<https://devfeed.tech/tags/enterprise-technology.md>), [reliability](<https://devfeed.tech/tags/reliability.md>), [software](<https://devfeed.tech/tags/software.md>), [sponsor](<https://devfeed.tech/tags/sponsor.md>)

### AI overview

Temporal explains its front-of-shirt sponsorship of Crystal Palace by comparing the club's supporter loyalty with Temporal's focus on reliable software workflows. The article also mentions Temporal's reported $300 million Series D and $5 billion valuation.

### Source excerpt

Temporal and Crystal Palace are teaming up, uniting fan and developer communities built on a loyalty that's earned, not manufactured.

## Introducing Temporal's new Build, Operate, and Secure org, led by Preeti Somal

DevFeed: [Introducing Temporal's new Build, Operate, and Secure org, led by Preeti Somal](<https://devfeed.tech/articles/introducing-temporal-s-new-build-operate-and-secure-org-led-by-preeti-somal-35894.md>)

Original publisher: [Read original article](<https://temporal.io/blog/introducing-temporals-build-operate-secure-org-preeti-somal>)

Author: Preeti Somal

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

Content type: release

Language: en

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

Topics: [Development](<https://devfeed.tech/topics/development.md>), [Software Engineering](<https://devfeed.tech/topics/software-engineering.md>), [distributed-systems](<https://devfeed.tech/topics/distributed-systems.md>)

Tags: [announcements](<https://devfeed.tech/tags/announcements.md>), [engineering](<https://devfeed.tech/tags/engineering.md>), [organization](<https://devfeed.tech/tags/organization.md>), [reliability](<https://devfeed.tech/tags/reliability.md>), [software-development](<https://devfeed.tech/tags/software-development.md>)

### AI overview

Temporal announces a new Build, Operate, and Secure organization led by Preeti Somal as EVP. The organization brings Engineering, Product, and Design together under one charter to build, operate, and secure the company's products, with goals including faster iteration, a more consistent product experience, and continued reliability.

### Source excerpt

Temporal announces a new Build, Operate, and, Secure org led by EVP Preeti Somal, uniting Engineering, Product, and Design under one charter.

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