Copy-and-Replay vs Branch-at-a-Point: Two Backup Recovery Paths
A side-by-side comparison of copy-and-replay recovery and branch-at-a-point restores, showing why restore time scales with data size in one model and not the other.
Loading…
Topic
Reliability
284 posts about Reliability. Every summary links to the original.
- 284 posts
- 45 companies
- 2 explainers
See the idea
Reliability explainers
The SQS Decision Most Diagrams Skip: Normal Work vs. Broken Work
Amazon SQS connects producers and workers, but its real design test is failure. Compare the processing path with the signals and controls needed when queue operations break.
The Good Stuff
Paid picks we use ourselves. Links carry a referral code — a subscription through one earns us a commission at no extra cost to you.
Newest first
Posts
Errors, traces, logs, metrics: when to reach for what
Modern application telemetry relies on four overlapping signals: errors, traces, logs, and metrics. Each telemetry type addresses distinct engineering questions and powers specific debugging workflows. Errors track grouped, actionable application crashes, whereas traces map timing and execution paths across dependency waterfalls. Metrics aggregate numerical measurements across historical deployments, and logs preserve complete state and decision-making context at specific moments in execution. Emitting telemetry directly into the format needed for a given workflow proves superior to relying on a single wide event, as tools like AI coding agents require structured spans to optimize execution paths while human debuggers rely on unsampled logs and metrics to pinpoint silent failures.
Sitar-agent: Building a reliable dynamic configuration sidecar at scale
Airbnb modernized sitar-agent, a Kubernetes sidecar that delivers dynamic configuration updates to thousands of polyglot service instances without requiring redeployments. The architecture uses periodic AWS S3 snapshots to enable fast, decoupled pod startups and maintains local file-based storage for the main container to read configs with in-memory caching. Key design decisions include retaining an isolated sidecar over an in-process library and optimizing pull-based polling with server-side caching.
Multigres v0.1 Alpha: an operating system for Postgres
Multigres v0.1 alpha is an open-source release of a system intended to provide Vitess-grade horizontal scaling, high availability, and operational simplicity for Postgres. It manages Postgres instances with sharding, connection pooling, automatic failover, and backup orchestration, while this release adds advanced pooling, automatic failovers, and a Kubernetes operator. Its high-availability protocol builds on unmodified Postgres replication, supports user-defined durability policies, resolves split-brain scenarios without losing succeeded commits, and permits replica changes while running. The release is suitable for experimentation but not production workloads: v0.1 is single-shard, sharding is absent, the custom-resource API may change, backward compatibility is not guaranteed, and performance benchmarks are still in progress.
Direct Preference Optimization Beyond Chatbots
DharmaOCR applies Direct Preference Optimization (DPO) beyond chat alignment to reduce text degeneration in structured OCR, where outputs are either acceptable transcriptions or failure loops. In a benchmark of Brazilian Portuguese structured-document OCR, vanilla degeneration rates among open-source model families ranged from below 1% to above 33%, while supervised fine-tuning (SFT) did not consistently reach production-acceptable levels. After SFT, the pipeline generated multiple candidates for 23,726 documents, used an automated LLM judge to score them, and retained the model’s degenerate outputs as rejected examples paired with chosen outputs. DPO reduced degeneration in every tested family, by 59.4% on average and up to 87.6%, without reducing extraction quality according to the benchmark; applicability is presented as dependent on failures being categorically identifiable, reliably scoreable, and sufficiently numerous.
Enterprise Business Software and the Mixed-Up Chameleon Problem
Traditional ERP practice prioritizes a standardized, stable core, but the post argues that forcing every process into it can erode an organization’s identity and differentiated ways of creating value. It proposes keeping the ERP as the system of record while placing an interoperability layer above it. This layer uses a shared ontology to reconcile concepts across systems and supports workflows, automation, user experiences, agentic AI, and human engineering under shared security and governance. Because these capabilities remain outside the core, organizations can preserve distinctive processes during ERP upgrades and treat migration as a continuous software- and ontology-driven activity rather than a one-time manual exercise. The intended model is structured adaptability: standardized ERP functions retain discipline, auditability, and financial integrity while operational software adapts to the business.
Compliance versus conversion: Tax ID validation at checkout
Tax ID collection at checkout supports compliant tax invoices and tax determination, including reverse-charge treatment for qualifying cross-border business transactions. Validation can be performed synchronously before purchase completion or asynchronously after checkout: synchronous checks reduce correction and audit risk but may increase abandonment and expose conversion to government-service downtime, while asynchronous checks preserve completion but require follow-up on failures. The implementation discussion covers direct national-registry integrations, third-party validation services, and Stripe’s CheckoutSessions and PaymentIntents integrations, where the Tax ID Element uses verification modes of if_supported or none. Stripe first applies a country-specific format check, routes validly formatted IDs to government APIs, may fall back to asynchronous processing after four seconds, and exposes status through customer.tax_id.updated and the customer object.
Slack AI: The Path to Multi-Cloud
Slack evolved its Slack AI serving infrastructure across multiple phases to handle enterprise LLM workloads reliably and securely. The initial deployment on AWS SageMaker provided zero-knowledge escrow VPC isolation and FedRAMP compliance, but engineers faced scaling latency, GPU scarcity, and significant operational overhead. Slack then migrated live traffic to Amazon Bedrock to leverage managed Model Units and eliminate model release lag without customer-facing incidents. However, fixed Provisioned Throughput commitments and regional peak traffic variations created persistent underutilization challenges. Consequently, Slack expanded into a multi-cloud orchestration architecture that normalizes disparate provider APIs, integrates unified cross-cloud telemetry, and routes traffic dynamically around latency spikes and outages.
amazon.science
How flat is replacing fat in AWS data center networks
Traditional data center networks rely on hierarchical fat-tree topologies, which introduce overhead, upper-layer congestion, and vulnerability to router failures. Although flat random networks theoretically maximize route diversity and resilience, routing computation and cabling complexity historically made them impractical for physical data centers. AWS addressed these constraints by introducing Resilient Network Graphs, a quasi-random architecture powered by a passive optical device called ShuffleBox and a routing algorithm named Spraypoint. Spraypoint sprays packets across random neighbors toward designated waypoints, unlocking twice as many independent paths while operating within commodity router memory limits. Adopted as the default architecture across new AWS facilities, this design reduces router counts by 69%, lowers projected network power consumption by 40%, and increases throughput by up to 33%.
Under the River
Shopify describes how its AI agent, River, grew from an infrastructure bet aimed at making a large, fragmented codebase usable by AI. In early 2024, the company adopted a monorepo called World and Nix as a reproducible substrate for development, CI, and production, despite substantial migration costs. River operates in public Slack channels, where it reads code, runs tests, queries data, inspects production traces, and opens pull requests; in a recent 30-day period it handled 59,918 sessions and contributed to 3,536 merged pull requests. Underneath it, Aquifer provides durable sessions, sandboxes, gateways, event logs, credentials handling, and observability, allowing agent profiles to share one platform across interactive, automated, and batch modes. The central design principle is that the session must survive process and machine failure, while public transcripts create a compounding knowledge corpus.
How the lakebase architecture stays resilient to cloud failures
Lakebase is adapting its reliability architecture to agentic and on-demand workloads, which create far more control-plane activity, database starts, and pressure on finite cloud capacity. Lakebase uses stateless Postgres compute over zone-resilient storage, dedicated multi-availability-zone computes for optional high availability, and a vertically autoscaling virtualization layer that reduces dependence on cloud provisioning control planes. A dedicated data-plane controller is being developed for hot-path start and suspend operations, while cell-based regional deployments isolate failures and allow capacity to expand incrementally. The reliability program also uses component and whole-availability-zone failure injection, consistency checks, Service Level Indicators, and Service Level Objectives, including startup, failover, storage, and API measurements. The stated target is for every database to exceed 99.99% monthly availability; reported 2026 attainment through April shows 99.75% to 99.85% of databases meeting that threshold.
Modern Java at Stripe: Language upgrades as a service
Large JVM codebases often stall Java upgrades because build-graph constraints require coordinated changes across many owners, while manual scripts and stale inventories repeatedly rediscover blockers. Stripe built AutoJDK to continuously analyze the live build graph, compute eligibility using reverse-dependency, runtime, framework, and dependency-ordering constraints, and generate bounded, idempotent pull requests rather than opaque rewrites. It also tracks adoption and blocker categories, uses AI assistance for selected remediation tasks, and can operate continuously or on specified packages and services. Centralized JDK and runtime policy, CI checks, multi-JDK support, static analysis, and packaging applications with platform-specific JDKs support gradual transitions. After three months, the upgrader had merged more than 160 PRs, made JDK 17 the most common target, eliminated Java 8 services, and reduced the JDK 8 and 11 footprint by roughly 25K targets.
Protecting your Supabase projects from npm supply chain attacks
The post explains why npm supply-chain attacks matter to Supabase projects: Edge Functions, the Supabase CLI, and packages including supabase-js, @supabase/ssr, and @supabase/server all depend on npm. Attackers can compromise maintainers, register typosquats, or exploit build pipelines; once malicious code reaches node_modules, lifecycle scripts may read environment variables, cloud metadata, tokens, kubeconfig, and SSH keys. The proposed defense is layered: upgrade to pnpm 11, increase minimumReleaseAge to several days, pin sensitive dependency versions, commit and review lockfiles, disable or allowlist install scripts, verify package names, and pin GitHub Actions to full commit SHAs. Supabase is publishing a canonical security guide, hardening its GitHub Actions, adding secret-handling warnings to API documentation, and coordinating communications; the post also recommends rotating credentials after a potentially compromised install and using scanners as supplementary defense.
Using observability data to prevent incidents
Engineering teams often remain reactive not because they lack telemetry, but because metrics, logs, traces, error budgets, and SLO burn rates are difficult to query at decision speed. The post frames reliability intelligence as trend analysis that identifies accumulating risk before a user-facing incident, contrasting it with observability focused on current system state. It proposes unified telemetry access and natural-language self-service, using Databricks Genie to examine p99 latency, error-budget burn, deployment frequency, incident rates, dependencies, and capacity across services. The Trade Desk’s Genie Router handles questions across more than 10,000 tables, while the post says ad-hoc analysis runs five times faster with Genie and can support mitigation before a page fires.
Introducing Nova, our internal platform for coding agents
Dropbox developed Nova, an internal platform that runs AI coding agents in isolated cloud environments integrated with their Bazel monorepo. The platform supports both interactive developer workflows and autonomous background tasks, such as automated CI debugging, flaky test remediation, and codebase-wide migrations. By pairing code generation with automated validation and strict execution guardrails, Nova ensures generated fixes are tested and reproducible.
The product analytics you already have
Software engineers frequently rely on separate product analytics tools and teams to answer user behavior questions, creating disjointed data models and delayed insights. Existing debugging telemetry within tools like Sentry—specifically spans, structured logs, and application metrics—can serve as the primary source for product metrics. Developers enrich request spans with business-level attributes, record discrete business events through wide structured logs, and track KPIs with metric counters and distributions. This unified telemetry links business outcomes directly to underlying traces, errors, releases, and source code lines, enabling immediate root-cause analysis and automated alerts. While multi-session cohort and funnel aggregation remains a current tooling gap, standard telemetry solves day-to-day adoption, performance, and revenue questions.
Coding Agent Horror Stories: The Security Crisis Threatening Developer Infrastructure
Autonomous AI coding agents increasingly handle developer workflows, but their execution model introduces critical security risks. Operating with the executing user's full permissions, these agents can read ambient secrets, inherit cloud credentials, and run destructive shell commands without human intervention. Documented incidents between October 2024 and February 2026 reveal systemic hazards, including unintentional home directory deletions and increased security vulnerabilities in generated code. To address these vulnerabilities, Docker Sandboxes isolate agent execution within dedicated microVMs, preventing access to the host filesystem and blocking common credential paths by default. Routing changes through Git worktrees and restricting network egress ensures that agent actions remain strictly bounded and reviewable before affecting main branches or production infrastructure.
Operator: A look under the hood
Operator is a customer-operations Agent built to help teams understand, manage, and improve customer experience across workspaces. The post distinguishes a production Agent from a prototype that simply gives an LLM API access and a system prompt, describing more than 50 purpose-built tools and 10 skills for data retrieval, reporting, investigation, and operational tasks. Its intelligence layer combines semantic search tuned against millions of support conversations, workspace-specific attribute awareness, and encoded reasoning, while the action layer supports configuration and content changes through reviewable diffs requiring explicit approval. A hybrid conversational and graphical interface presents charts, dashboards, and structured proposals within the existing platform. The post argues that read-only custom tools can be built in weeks, but production reliability, safe actions, multi-tenant isolation, graceful degradation, and ongoing maintenance require substantially greater investment.
We replaced Redis with MySQL for inventory reservations—and it scaled
Shopify replaced its Redis-based inventory reservation system with MySQL to unify reservations with the inventory ledger and provide ACID coordination between payment and inventory updates. The new design stores one row per sellable unit in a bounded pool of up to 1,000 rows per item/location combination, uses MySQL 8's SKIP LOCKED to avoid waiting on locked units, and replenishes depleted pools. Composite primary keys reduced row locks, READ COMMITTED avoided gap locks that interfered with replenishment, and consistent lock ordering prevented deadlocks. The investigation found connection-pool usage elsewhere in checkout, rather than reservation query speed alone, was the immediate ceiling; cleanup removed 50% of primary-database reads and 33% of transactions, while configuration changes added headroom. Shopify validated the design in shadow mode, then rolled it out gradually with a Redis rollback path, meeting high-throughput targets during peak 2025 traffic.
vLLM V0 to V1: Correctness Before Corrections in RL
PipelineRL migrated its rollout inference engine from vLLM V0 (0.8.5) to V1 (0.18.1), but trainer-side logprobs, policy ratios, KL, entropy, clip rate, and reward diverged from the V0 reference. The investigation separated semantic mismatch, inference-path mismatch, and objective mismatch, then prioritized backend parity before changing the RL objective. Fixes included processed rollout logprobs, explicit V1 runtime settings disabling prefix caching and async scheduling, a V0-like inflight weight-update path, and an fp32 lm_head for the final projection. With those changes, the final V1 run tracked the V0 trajectory across the reported metrics, while processed_logprobs alone did not resolve the training gap.
amazon.science
Navigating uncertainty in Amazon's middle-mile network
Amazon's middle-mile logistics network coordinates tens of millions of packages across hundreds of facilities while managing subtle demand variations and major operational disruptions. To solve this mixed-integer optimization challenge without combinatorial explosion, Amazon models routes at coarse time resolutions augmented by precomputed 15-minute timing bounds. The system uses Monte Carlo methods alongside a graph attention network featuring interconnected site graphs and origin-destination graphs to capture complex spatial correlations and flow interdependencies. By generating synthetic flow permutations, planners stress-test candidate network designs against hundreds of plausible scenarios to prioritize routing optionality. This risk-aware modeling approach preserves network flexibility, absorbs severe shocks, and yields potential cost savings while safeguarding delivery promises.
Related topics
All topics →Weekly digest
The best engineering reads, once a week.