# async Published articles for async. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## Fault tolerant distributed training on Amazon EKS using NVRx DevFeed: [Fault tolerant distributed training on Amazon EKS using NVRx]() Original publisher: [Read original article]() Author: Aravind Neelakantan Published: 2026-09-16T18:59:25Z Content type: tutorial Language: en Sources: [Artificial Intelligence]() Topics: [NCCL](), [Amazon Elastic Kubernetes Service](), [PyTorch](), [distributed-training](), [Resilience](), [GPU]() Tags: [advanced-300](), [amazon-eks](), [amazon-elastic-kubernetes-service](), [async](), [benchmarks](), [distributed-training](), [gpu](), [pytorch](), [resiliency](), [technical-how-to]() ### AI overview This tutorial integrates NVIDIA Resiliency Extension (NVRx) with PyTorch FSDP training on Amazon EKS. It covers asynchronous checkpointing, in-process restart, and in-job restart, and reports H100 benchmarks at 2- to 8-node scale with 99%+ training efficiency and recovery measured in seconds. ### Source excerpt Integrate NVIDIA Resiliency Extension (NVRx) into PyTorch FSDP training on Amazon EKS to overlap checkpoint I/O with training and recover from GPU faults in seconds. This post covers async checkpointing, in-process restart, and ft_launcher in-job restart, with H100 benchmarks at 2 to 8 nodes showing 99%+ training efficiency and second-scale recovery. ## Calling the WorkOS API from server-side Swift DevFeed: [Calling the WorkOS API from server-side Swift]() Original publisher: [Read original article]() Author: WorkOS Published: 2026-09-15T00:00:00Z Content type: tutorial Language: en Sources: [WorkOS Blog]() Topics: [Swift](), [API](), [Back end](), [SDK](), [Vapor]() Tags: [api](), [async](), [backend](), [sdk](), [swift]() ### AI overview This article explains how to call the WorkOS API from trusted server-side Swift applications. It covers typed resource clients, structured errors, automatic retries for transient failures, and AsyncSequence-based pagination. ### Source excerpt Typed resources, structured errors, automatic retries, and AsyncSequence pagination for server-side Swift apps. ## Async GRPO with LoRA across HF Jobs: a bucket, a proxy, and no NCCL DevFeed: [Async GRPO with LoRA across HF Jobs: a bucket, a proxy, and no NCCL]() Original publisher: [Read original article]() Author: Amine Dirhoussi; Quentin Gallouédec; Kashif Rasul; Sergio Paniego Published: 2026-09-10T00:00:00Z Content type: article Language: en Sources: [Hugging Face - Blog]() Topics: [lora](), [grpo](), [jobs](), [vllm](), [NCCL](), [async](), [hugging face]() Tags: [async](), [grpo](), [hub](), [hugging-face](), [jobs](), [llm](), [lora](), [nccl](), [open-source](), [rl](), [storage](), [trl](), [vllm]() ### AI overview This article describes asynchronous GRPO training with a LoRA adapter across separate Hugging Face Jobs. The adapter is synchronized to vLLM replicas through a shared Storage Bucket, while a proxy handles authentication, rollout routing, and adapter-load broadcasts. Five runs reduced the time for 500 steps from 3 hours 27 minutes to 53 minutes. ### Source excerpt We're on a journey to advance and democratize artificial intelligence through open source and open science. ## CodeSOD: Asynchronous Directories DevFeed: [CodeSOD: Asynchronous Directories]() Original publisher: [Read original article]() Author: Remy Porter Published: 2026-09-09T06:30:00Z Content type: article Language: en Sources: [The Daily WTF]() Topics: [Vala](), [async/await](), [Library](), [Programming]() Tags: [async](), [asynchronous](), [await](), [codesod](), [exceptions](), [filesystem](), [writing-code]() ### AI overview This article examines implementing an asynchronous version of Vala's directory-creation method when the core library provides only a synchronous version. The proposed function walks up the directory tree, then creates missing directories in reverse order, using exceptions for control flow. ### Source excerpt Eri has a mix of a "true confession" and a "wait, really?" today. The programming language Vala bills itself as a C# like language that compiles into something pretty close to C performance, designed specifically for writing code against Gnome and its associated libraries. One of the C#-isms in brings in is async/await type semantics. You can yield someAsyncFunction(), which returns control to the caller, allowing it to proceed until the yielded function returns an actual value. Because it has asynchronous functions, many library functions for handling I/O are already async. So you can make_directory_async, which yields control so you can keep executing while waiting for the filesystem to make your directory. There are also synchronous versions of those methods. And then there's create_directory_with_parents, which will create a chain of directories for you. That's the synchronous version, and Vala's core library has decided not to provide an asynchronous version of it, which is my "wait, really?" I suspect it's really about the race conditions involved and the risks of things going wrong while doing it asynchronously; all solvable problems, but tricky ones to solve. But it's the problem Eri had, and this is their solution: /// Note: does not throw if target already exists async void create_directory_with_parents_async(File file, Cancellable? cancellable = null) throws Error { var to_create = new File[0]; var? current_target = file; while(current_target != null) { try { yield current_target.make_directory_async(Priority.DEFAULT, cancellable); } catch(IOError.NOT_FOUND e) { to_create += current_target; current_target = current_target.get_parent(); continue; } catch(IOError.EXISTS e) { break; } break; } for (int i = to_create.length - 1; i >= 0; --i) { try { yield to_create[i].make_directory_async(Priority.DEFAULT, cancellable); } catch(IOError.EXISTS e) { // Created by another process } } } If I'm reading this correctly, we start by trying to create the full path to ## wasmCloud 2.8: Async messaging, admission control, and a backstop for runaway guests DevFeed: [wasmCloud 2.8: Async messaging, admission control, and a backstop for runaway guests]() Original publisher: [Read original article]() Author: Eric Gregory Published: 2026-08-26T00:00:00Z Content type: release Language: en Sources: [wasmCloud Blog]() Topics: [Messaging](), [Resilience](), [configuration]() Tags: [async](), [interfaces](), [memory](), [messaging](), [wasmcloud]() ### AI overview wasmCloud 2.8.0 introduces asynchronous messaging interfaces with streamed payloads, typed errors, and timeouts. It also adds admission control for messaging deliveries, detects guests that consume CPU without yielding, exposes wasmtime memory tuning through Helm, and tightens related defaults. ### Source excerpt wasmCloud 2.8 ships the async wasmcloud:messaging 0.3.0 interfaces with streamed payloads, brings messaging deliveries under admission control, opens up wasmtime memory tuning, and reclaims CPU from guests that never yield. ## Native Async/Coroutine Reads in RocksDB DevFeed: [Native Async/Coroutine Reads in RocksDB]() Original publisher: [Read original article]() Author: Josh Kang Published: 2026-08-24T00:00:00Z Content type: release Language: en Sources: [RocksDB]() Topics: [rocksdb](), [Coroutines](), [C++](), [IO](), [API]() Tags: [async](), [asynchronous](), [blog](), [c-plus-plus](), [coroutine](), [io](), [native](), [rocksdb](), [thread]() ### AI overview RocksDB introduces experimental asynchronous Get and MultiGet APIs backed by native C++ coroutines. The APIs can suspend storage-bound reads, allowing a small executor to run other ready tasks and maintain more storage queue depth without one blocked application thread per read. The feature targets throughput for I/O-bound point lookups rather than reducing individual device-read latency. ### Source excerpt A point lookup that misses RocksDB's block cache can spend most of its time waiting for storage. The traditional way to keep more reads in flight is to add threads. That works, but each outstanding read parks a thread, carries a stack, and adds context-switching overhead. RocksDB now has experimental asynchronous Get and MultiGet APIs backed by native C++ coroutines. When a read reaches storage, RocksDB can suspend the request, let its read-executor worker run another ready task, and resume the request when the filesystem reports completion. A small executor can therefore maintain more storage queue depth without requiring one blocked application thread per read. These APIs are available in RocksDB 11.10.0. This is primarily a throughput feature for I/O-bound point lookups. It does not make an individual device read faster. Its benefit comes from keeping the device busy and using CPU threads for runnable work. The API surface RocksDB exposes the new read path through two public interfaces: DB::GetAsync and DB::MultiGetAsync return immediately on the native path and report completion through AsyncCallback::OnComplete. CoroDB::CoGet and CoroDB::CoMultiGet return lazy folly::coro::Task objects. CoGet produces a Status; CoMultiGet fills the same per-key values and statuses as synchronous MultiGet. The callback APIs suit applications that do not expose Folly tasks at their boundaries. The CoroDB APIs let coroutine-based callers await RocksDB directly, avoiding an application-side callback-to-Baton adapter and its extra completion handoff. Native execution requires RocksDB to be built with Folly and USE_COROUTINES=1. Neither interface requires ReadOptions::async_io. That flag continues to control the older internal async-I/O optimizations for synchronous MultiGet and iterators. The task APIs are lazy: no read begins until a task is awaited or started. Both interfaces take pointer and reference parameters, so keep the DB, column-family handles, ReadOptions, keys and their ## Coroutine Essentials DevFeed: [Coroutine Essentials]() Original publisher: [Read original article]() Author: author@typealias.com (Dave Leeds) Published: 2026-08-21T00:00:00Z Content type: tutorial Language: en Sources: [Dave Leeds on Kotlin - typealias.com]() Topics: [Coroutines](), [Kotlin](), [coding](), [Software]() Tags: [async](), [cancellation](), [coding](), [concurrency](), [coroutine](), [coroutines](), [deferred](), [dispatcher](), [exception-handling](), [introduction](), [job](), [kotlin](), [launch](), [learn-to-program](), [parallelism](), [programming](), [runblocking](), [software](), [structured-concurrency](), [suspend-function](), [withcontext](), [yield]() ### AI overview This tutorial introduces essential Kotlin coroutine concepts for performing multiple tasks concurrently, such as making network calls while updating a screen. It aims to provide a foundation for day-to-day coding and more advanced coroutine concepts. ### Source excerpt When you're on hold during a phone call, you might also check your email. While brewing coffee, you might also cook breakfast. And while driving a car, you might listen to a podcast. In the same way, sometimes it's helpful for the software that we write to do more than one thing at a time. For example, it could make two or three network calls at one time--all while updating the screen to show the progress of each call. ## Postgres 19: How Our Advice Has Changed Since We Wrote It DevFeed: [Postgres 19: How Our Advice Has Changed Since We Wrote It]() Original publisher: [Read original article]() Author: Christopher Winslett Published: 2026-08-18T19:00:00Z Content type: article Language: en Sources: [CrunchyData Blog]() Topics: [data](), [JIT](), [Latency](), [Temporal data](), [Linux]() Tags: [advice](), [async](), [benchmarks](), [index](), [jit](), [latency](), [linux](), [maintenance](), [parallel](), [partitioning](), [postgres](), [postgres-19](), [production-postgres](), [release](), [storage](), [upgrade]() ### AI overview This article revisits earlier Crunchy Data guidance on loading, storage, indexes, and partitioning for the upcoming Postgres 19 release. It explains which changes in Postgres 18 and 19 affect that advice, including asynchronous I/O, parallel maintenance, BRIN and skip-scan behavior, partition operations, and JIT being disabled by default. The details are based on current betas and may change before general availability. ### Source excerpt Revisiting Crunchy posts on COPY, TOAST, BRIN, covering indexes, and partitioning: what we said then, which Postgres versions changed the story, and what we recommend on Postgres 19. ## Scrapli vs Nornir: What's the Difference DevFeed: [Scrapli vs Nornir: What's the Difference]() Original publisher: [Read original article]() Author: Roger Perkin Published: 2026-08-06T11:08:45Z Content type: comparison Language: en Sources: [Roger Perkin Network Automation Consultant]() Topics: [Python](), [Network](), [async](), [NETCONF](), [ssh]() Tags: [async](), [netconf](), [network-automation](), [python](), [scrapli](), [ssh](), [vs]() ### AI overview This comparison explains that Scrapli and Nornir address different layers of Python network automation rather than directly competing. It describes Scrapli as a connection-focused library for communicating with individual network devices and notes its support for SSH, Telnet, NETCONF, synchronous and asynchronous operation, and structured output. ### Source excerpt If you've spent any time in the Python network automation world, you'll have bumped into both Scrapli and Nornir. They come up in the same conversations, the same blog posts and the same job specs, so it's natural to line them up and ask: which one should I use? It's a fair question, but it's built on a slightly ... ## How to Handle Global Errors in Modern Zoneless Angular DevFeed: [How to Handle Global Errors in Modern Zoneless Angular]() Original publisher: [Read original article]() Author: Jaroslaw Zolnowski Published: 2026-08-04T11:51:30Z Content type: tutorial Language: en Sources: [Daniel Glejzner]() Topics: [Angular](), [Error Handling](), [Web Development]() Tags: [angular](), [async](), [errors](), [exceptions](), [how-to](), [modern](), [user-experience](), [web-development]() ### AI overview This tutorial explains why global error handling changes when Angular applications move from Zone.js to a zoneless model. It introduces provideBrowserGlobalErrorListeners as an Angular v20 tool for handling errors that occur outside Angular's direct control, including unhandled Promise rejections and third-party scripts. ### Source excerpt In the world of web development, unhandled errors are silent threats. They can degrade user experience, cause unpredictable application behavior, and leave developers in the dark. For years, Angular's error handling has benefited from a bit of "magic" ## Building an AI Agent for LinkedIn Scraping & Candidate Sourcing DevFeed: [Building an AI Agent for LinkedIn Scraping & Candidate Sourcing]() Original publisher: [Read original article]() Author: Pranshu Raj Published: 2026-07-23T00:00:00Z Content type: tutorial Language: en Sources: [Pranshu Raj - blog on backend systems, performance and sidequests]() Topics: [AI Agent](), [Artificial Intelligence](), [FastAPI](), [Python](), [Large Language Model](), [GitHub](), [data]() Tags: [agent](), [ai](), [ai-agent](), [async](), [fastapi](), [github](), [llms](), [pipeline](), [python](), [recruiting](), [scraping]() ### AI overview A developer describes building an AI-powered LinkedIn candidate-sourcing agent for a hackathon. The Python and FastAPI application combines LinkedIn and GitHub profile discovery, six-factor candidate scoring, and Llama-powered personalized outreach, using external services for search and LinkedIn data retrieval. ### Source excerpt How I built an AI agent that scrapes LinkedIn, scores candidates, and generates personalized outreach, a full recruiting sourcing pipeline in Python and FastAPI. ## Community Comebacks, Angular 21.1 Features, and Smarter Signal Forms ⚡ DevFeed: [Community Comebacks, Angular 21.1 Features, and Smarter Signal Forms ⚡]() Original publisher: [Read original article]() Author: Angular Published: 2026-06-19T10:01:04Z Content type: article Language: en Sources: [Angular]() Topics: [Angular](), [Forms](), [async](), [Open Source](), [legacy](), [migration]() Tags: [angular](), [angular-newsletter](), [angular-release](), [angular-weekly](), [async](), [asynchronous](), [forms](), [legacy](), [migration](), [open-source]() ### AI overview This Angular community roundup covers podcast episodes about Angular 20 and developer career setbacks, a recap of Angular 21.1, Signal Forms techniques for asynchronous validators and debouncing, dynamic form lists, an interview about joining the Angular team, and migration to modern Control Flow syntax. ### Source excerpt The Angular community is about much more than just code -- it's about the people building it, their career journeys, and how we collaborate. This week's roundup features inspiring community stories alongside technical deep dives into the Angular 21.1 features and advanced form tuning. Tune into this week's excellent community resources The Dev Life Podcast: Inside Angular 20 & Navigating Layoffs Brooke Avery @JediBravery and Matthew Christiansen back-to-back drop two must-listen episodes of The Dev Life podcast. First, they sit down with Minko Gechev @mgechev to go inside the engineering decisions of Angular 20. Then, they host GDE Chris Perko for an incredibly timely, candid conversation about bouncing back from tech layoffs and turning career setbacks into massive opportunities. Listen to Ep. 3 (Inside Angular 20): https://www.youtube.com/watch?v=QhfXXXzOD6g Listen to Ep. 4 (Navigating Layoffs): https://www.youtube.com/watch?v=laYzvyEDtw8 What was new in Angular 21.1? Alain Chautard @AlainChautard provides a fantastic, concise recap of the January Angular release. If you want to know what minor features, bug fixes, and performance polishes landed in Angular 21.1, this is your go-to guide. Read the release recap: https://blog.angulartraining.com/whats-new-in-angular-21-1-7454f699104f Stop Wasting API Calls! Async Validators & Debouncing Fanis Prodromou @prodromouf tackles a massive real-world performance issue in form handling. Learn how to combine asynchronous validators with debouncing in the Signal Forms API to keep your backend from being overwhelmed by unnecessary API requests. Watch the tutorial: https://youtu.be/R10dQ4zlWs0 Dynamic Lists & Joining the Angular Team (French) Modeste Assiongbon @rblmdst shares two incredible French-language videos this week. Dive into a technical walkthrough on handling dynamic field lists using Signal Forms. Then, catch an inspiring interview with Matthieu Riegler @Jean_Meche, tracking his journey from a casual open-source cont ## How Monk migrated 100+ workflows from Inngest to Temporal DevFeed: [How Monk migrated 100+ workflows from Inngest to Temporal]() Original publisher: [Read original article]() Author: Francesco Coacci Published: 2026-06-16T00:00:00Z Content type: article Language: en Sources: [Temporal Blog]() Topics: [migration](), [Orchestration](), [business logic](), [test-coverage]() Tags: [async](), [automation](), [business-logic](), [community](), [coverage](), [migration](), [orchestration](), [pull-request](), [workflows]() ### AI overview Monk describes migrating more than 100 live workflows from Inngest to Temporal incrementally, using reversible pull requests, parallel runtimes, feature-flagged cutovers, and no migration freeze. The article explains how this approach kept each workflow coherent and recoverable during the transition. ### Source excerpt Monk migrated 100+ live workflows from Inngest to Temporal with one reversible PR at a time all while avoiding freezes and rewrites. Here's how. ## WASI 0.3 Launched DevFeed: [WASI 0.3 Launched]() Original publisher: [Read original article]() Author: \["Bailey Hayes", "Yosh Wuyts"\] Published: 2026-06-11T00:00:00Z Content type: release Language: en Sources: [Bytecode Alliance]() Topics: [WebAssembly](), [toolchain]() Tags: [async](), [component](), [components](), [native](), [support](), [toolchain](), [wasi](), [webassembly]() ### AI overview WASI 0.3.0 has been ratified as a stable specification. It rebases WASI on the WebAssembly Component Model's native async primitives, making most changes from WASI 0.2 mechanical and simplifying interface signatures. Runtime and toolchain support is beginning to land. ### Source excerpt WASI 0.3 is official, and async is now native to WebAssembly Components. The WASI Subgroup voted to ratify WASI 0.3.0, rebasing WASI onto the WebAssembly Component Model's async primitives. The 0.3.0 specification is now stable, and runtime and toolchain support is landing now. ## The Road to Component Model 1.0 DevFeed: [The Road to Component Model 1.0]() Original publisher: [Read original article]() Author: Eric Gregory Published: 2026-06-08T00:00:00Z Content type: article Language: en Sources: [Bytecode Alliance]() Topics: [WebAssembly](), [wasm](), [browser]() Tags: [apis](), [architecture](), [async](), [binaries](), [browser](), [compatibility](), [interfaces](), [polyfill](), [production](), [wasi](), [wasm](), [webassembly]() ### AI overview This article explains the path toward a stable, formally specified WebAssembly Component Model 1.0. It reviews how the Component Model and WASI relate, describes the Component Model as a foundational layer with WASI providing system-resource interfaces, and notes that both are already used in production while their specifications continue to evolve. ### Source excerpt WASI P3 is almost here, bringing native async support to the WebAssembly System Interface (WASI) and Component Model. In this post, we're looking to the next big milestone: a stable, formally specified Component Model 1.0. At February's Bytecode Alliance Plumbers Summit, Luke Wagner and Alex Crichton gave a preview of what the path to a stable 1.0 actually looks like. At Wasm I/O 2026 in Barcelona in March, Luke expanded on that vision. So let's take a look at where the Component Model is heading. ## 20 Mistakes That Quietly Destroy JavaScript/TypeScript Codebases (Part 2) DevFeed: [20 Mistakes That Quietly Destroy JavaScript/TypeScript Codebases (Part 2)]() Original publisher: [Read original article]() Author: The T-Shaped Dev Published: 2026-05-09T02:19:51Z Content type: tutorial Language: en Sources: [The T-Shaped Dev]() Topics: [JavaScript](), [TypeScript](), [Code](), [Node.js](), [Testing]() Tags: [async](), [code](), [javascript](), [memory-leaks](), [mistakes](), [node-js](), [patterns](), [test](), [typescript]() ### AI overview Part 2 of a JavaScript and TypeScript code-quality series presents common runtime and code-quality mistakes, including mutating function parameters, memory leaks from uncleared listeners, timers and subscriptions, and async cancellation issues. It includes fixes and testing or debugging guidance. ### Source excerpt Common JS/TS patterns that feel fine until they don't. 11 mistakes, before/after code for each. (11 min) ## Waiting for PostgreSQL 19 - Online enabling and disabling of data checksums DevFeed: [Waiting for PostgreSQL 19 - Online enabling and disabling of data checksums]() Original publisher: [Read original article]() Author: depesz Published: 2026-04-15T18:05:36Z Content type: article Language: en Sources: [select \* from depesz;]() Topics: [PostgreSQL](), [postgresql clusters](), [async](), [IO]() Tags: [async](), [background](), [background-work](), [checksums](), [data-checksum](), [io](), [pg19](), [postgresql](), [uncategorized](), [vacuum](), [waiting]() ### AI overview This article examines a PostgreSQL 19 patch that allows data checksums to be enabled or disabled while a cluster is running. The command is immediate, but rewriting every table and index occurs in the background and can require substantial I/O. The article also discusses cost-delay options for controlling the background worker. ### Source excerpt On 3rd of April 2026, Daniel Gustafsson committed patch: Online enabling and disabling of data checksums This allows data checksums to be enabled, or disabled, in a running cluster without restricting access to the cluster during processing. Data checksums could prior to this only be enabled during initdb or when the cluster is ... Continue reading "Waiting for PostgreSQL 19 - Online enabling and disabling of data checksums" ## How to Accept Payments in a FastAPI Backend DevFeed: [How to Accept Payments in a FastAPI Backend]() Original publisher: [Read original article]() Author: Ayush Agarwal Published: 2026-03-29T00:00:00Z Content type: tutorial Language: en Sources: [Dodo Payments Blog]() Topics: [FastAPI](), [Back end](), [Pydantic](), [Python](), [SDKs](), [API](), [Software as a service]() Tags: [api](), [async](), [backend](), [checkout](), [compliance](), [developer-tools](), [fastapi](), [how-to](), [merchant-of-record](), [payment-gateway](), [payments](), [python](), [sdk](), [swagger](), [tax](), [validation](), [verification](), [webhooks]() ### AI overview A tutorial on integrating Dodo Payments into a FastAPI backend. It covers asynchronous checkout sessions and webhooks, Pydantic request validation, signature verification, and using verified webhook events as the source of truth for payment state. ### Source excerpt Learn how to integrate Dodo Payments into your FastAPI backend with async webhook handlers, Pydantic validation, and secure signature verification. ## How Asynchronous Systems Trade Execution Order for Scale and Availability DevFeed: [How Asynchronous Systems Trade Execution Order for Scale and Availability]() Original publisher: [Read original article]() Author: Raul Junco Published: 2026-03-28T13:04:17Z Content type: article Language: en Sources: [System Design Classroom]() Topics: [systems](), [event driven](), [Availability]() Tags: [async](), [availability](), [consistency](), [event-driven](), [ordering](), [parallel](), [pipelines](), [queue](), [scale](), [state](), [systems]() ### AI overview The article explains how asynchronous systems improve scale, throughput, and availability by processing work in parallel, while making execution order and consistency harder to control. Queues, retries, and parallel consumers can reorder related events, producing incorrect final state even when every component succeeds. ### Source excerpt Many developers only realize it after consistency breaks. ## PostgreSQL 18 Upgrades for AI-Era Workloads and Operations DevFeed: [PostgreSQL 18 Upgrades for AI-Era Workloads and Operations]() Original publisher: [Read original article]() Author: Sebastian Insausti Published: 2026-03-20T08:00:00Z Content type: article Language: en Sources: [SeveralNines]() Topics: [PostgreSQL](), [Software as a service](), [Transactions]() Tags: [ai](), [aio](), [async](), [latency](), [maintenance](), [performance](), [postgresql](), [postgresql-18](), [replication](), [storage](), [upgrades](), [upgrades-patches]() ### AI overview This article examines PostgreSQL 18 upgrades for transaction, analytics, SaaS, event-data, and vector-search workloads. It focuses on operational improvements including asynchronous I/O, safer upgrades that retain optimizer statistics, improved multi-column indexes, UUIDv7 support, and logical replication enhancements. ### Source excerpt Today, we're asking PostgreSQL to do more and more, like handling both transactions and analytics, powering huge SaaS platforms, managing event data, and even dipping into AI-related tasks like vector search. This intense pressure highlights some pain points: slow, unpredictable reads, rigid indexing, complex setups, and risky major upgrades. PostgreSQL 18 directly addresses these real-world [...] The post PostgreSQL 18 Upgrades for AI-Era Workloads and Operations appeared first on Severalnines. ## Designing Resilient APIs: Failure-Handling Patterns for Distributed Systems DevFeed: [Designing Resilient APIs: Failure-Handling Patterns for Distributed Systems]() Original publisher: [Read original article]() Author: hello@ankit-rana.com Published: 2026-03-16T00:00:00Z Content type: tutorial Language: en Sources: [Ankit Rana | Mechanical Sympathy]() Topics: [distributed-systems](), [Resilience](), [API](), [Architecture & Design]() Tags: [api-design](), [apis](), [async](), [distributed-systems](), [fault-tolerance](), [idempotency](), [jitter](), [observability](), [outages](), [reliability](), [resilience](), [retries](), [systems]() ### AI overview A practical guide to designing resilient APIs in distributed systems. It covers fail-fast validation, graceful degradation, idempotency for safe retries, and bounded retry policies using exponential backoff, jitter, attempt limits, and total time budgets. ### Source excerpt Resilience is failing in controlled ways rather than not failing. Validate and fail fast at the boundary, degrade gracefully by serving cached or reduced responses, require an idempotency key for side-effecting operations, and bound retries with exponential backoff, jitter, an attempt cap, and a total time budget. Unbounded retries amplify outages. ## System Migration: Minimize Downtime, Maximize Efficiency DevFeed: [System Migration: Minimize Downtime, Maximize Efficiency]() Original publisher: [Read original article]() Author: hello@ankit-rana.com Published: 2026-03-16T00:00:00Z Content type: tutorial Language: en Sources: [Ankit Rana | Mechanical Sympathy]() Topics: [migration](), [systems](), [async](), [client](), [event driven](), [Kafka](), [API]() Tags: [apache-kafka](), [api](), [architecture](), [async](), [bridge-layer](), [data-pipelines](), [downtime](), [event-driven-architecture](), [metrics](), [migration](), [observability](), [production](), [reliability](), [rollback](), [system-migration](), [traffic-leakage]() ### AI overview A practical guide to migrating an existing system with minimal disruption. It recommends isolated-environment testing, load testing, adapters for incompatible contracts, synchronized asynchronous pipelines, a Kafka-based shared stream, a bridge layer, staged traffic switching, monitoring, and rollback preparation. ### Source excerpt Migrate behind a bridge layer that routes all client traffic and supports three modes: old-only, dual, and new-only. Run dual mode to compare responses without user impact, keep a back-sync pipeline so the old system stays current for rollback, and shift traffic in stages while watching metrics at each step. ## AI Slop: A Slack API Rate Limiting Disaster DevFeed: [AI Slop: A Slack API Rate Limiting Disaster]() Original publisher: [Read original article]() Author: Daniel Doubrovkine (dblock@dblock.org) Published: 2026-03-12T00:00:00Z Content type: article Language: en Sources: [Daniel Doubrovkine]() Topics: [Slack](), [API](), [Code]() Tags: [ai](), [api](), [async](), [code](), [concurrent](), [distributed-system](), [rate-limiting](), [retry](), [script](), [slack]() ### AI overview The article examines an AI-generated cleanup job for closing old Slack group DM conversations. Because Slack's conversations.close endpoint has a global rate limit of one request per second, the implementation could exhaust the limit and disrupt other API calls. The author describes mitigating the issue with scheduled execution, an opt-in setting, a slow-drain script, and limiting the number of DMs closed concurrently. ### Source excerpt Yesterday I described AI-generated code as "plausible-looking, locally coherent, globally wrong." Here's a concrete example from my own codebase. I needed a cleanup job to close old Slack group DM conversations in my slack-sup2 app. The AI-generated solution looked perfectly reasonable: def close_old_sups! return 0 unless sup_close old_sups = sups.where(conditions) old_sups.each(&:close!) old_sups.count end def close! return unless conversation_id return if closed_at logger.info "Closing DM channel #{conversation_id}..." slack_client.conversations_close(channel: conversation_id) update_attributes!(closed_at: Time.now.utc) end This code looks pretty great and completely breaks the app. Slack's API has a global rate limit of 1 request per second for the conversations.close endpoint. So, when this job runs against a workspace with hundreds of old conversations, it immediately hits the rate limit. Worse, because rate limits are global across all endpoints, it takes down the entire application. Every other API call -- posting messages, fetching user info, everything -- starts failing. I asked AI to address this. It made the fix catastrophically worse. def close! # ... existing code ... begin slack_client.conversations_close(channel: conversation_id) rescue Slack::Web::Api::Errors::TooManyRequests => e sleep_time = e.retry_after || 60 sleep(sleep_time) retry end # ... rest of method ... end In socketry/async, sleep() blocks the entire fiber and prevents other concurrent operations from executing. You should use Async::Task.sleep() instead, but that still doesn't solve the fundamental architectural problem of making hundreds of sequential API calls. What made this particularly insidious is that the assistant wrote some pretty professional-looking code and seemingly handled obvious edge cases. Yet, it failed to consider the distributed system constraints or global invariants. The rate limiting problem wasn't visible in the local scope of the method - it was a system-wide conc ## A Single Subscriber Doesn't Turn Pub/Sub Into a Queue DevFeed: [A Single Subscriber Doesn't Turn Pub/Sub Into a Queue]() Original publisher: [Read original article]() Author: Raul Junco Published: 2026-02-28T12:52:05Z Content type: tutorial Language: en Sources: [System Design Classroom]() Topics: [systems](), [API]() Tags: [api](), [async](), [patterns](), [pdf](), [queue](), [retry](), [systems]() ### AI overview The article explains that asynchronous system patterns should be classified by execution semantics rather than by the messaging technology used. A report-generation flow with one worker processing each job, retries after failure, and additional workers sharing increased demand is a work queue, not pub/sub. ### Source excerpt Why execution semantics -not tooling- define async patterns. [Next page]()