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
287 posts about Reliability. Every summary links to the original.
- 287 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
Carrying Complexity, Delivering Agility
MongoDB centers its engineering architecture around resilience, intelligence, and simplicity to minimize developer cognitive and operational burdens when building distributed applications. Security is enforced through dedicated clusters in isolated virtual private networks alongside Queryable Encryption, which allows equality and range queries on ciphertext without decryption keys ever leaving the client. High availability is built on replica sets across independent availability zones and multi-cloud topologies, utilizing consensus mechanisms that commit writes only after majority acknowledgment in the active term. Operational friction in artificial intelligence workloads is addressed by integrating vector search directly into the core query engine, eliminating brittle extract-transform-load pipelines and separate vector databases.
From Niche NoSQL to Enterprise Powerhouse: The Story of MongoDB's Evolution
Early perceptions categorized MongoDB alongside eventually consistent NoSQL databases, creating doubts regarding its suitability for mission-critical enterprise workloads. Over fifteen years of development, the platform addressed enterprise requirements by introducing replica sets with Raft-style consensus, native horizontal sharding, tunable read and write concerns, and multi-document ACID transactions across sharded clusters. Security capabilities were expanded through Role-Based Access Control, Field-Level Encryption, and Queryable Encryption supporting prefix, suffix, and substring searches. Current initiatives focus on decoupling compute and storage scaling, developing AI-driven tooling within the Application Modernization Platform to translate legacy relational applications to microservices, and optimizing query execution for non-denormalized data models. MongoDB Atlas now incorporates Atlas Search, Atlas Vector Search, native Stream Processing, and embedding generation powered by Voyage AI models.
MongoDB Community Edition to Atlas: A Migration Masterclass With BharatPE
BharatPE, an Indian fintech processing over ₹12,000 crore monthly across 450 cities, operated a 45-terabyte self-hosted MongoDB Community Edition deployment. Managing three sharded three-node clusters resulted in uneven data distribution, high maintenance costs, scaling friction, and disaster recovery gaps under strict regulatory requirements. To modernize infrastructure, the database operations team partnered with MongoDB to execute a structured five-stage migration to MongoDB Atlas. The initiative utilized mongosync for secure data transition alongside environment mirroring and automated integrity validation scripts. Transitioning to MongoDB Atlas yielded a 40 percent improvement in query response times and provided automated failover backed by a 99.995 percent uptime SLA.
How we built it: Real-time analytics for Stripe Billing
Stripe built a real-time streaming analytics system for Billing after customers said they needed to detect emerging behavior and adapt pricing quickly, replacing a batch pipeline whose subscription updates lagged by 24 hours on average. The architecture uses Apache Flink to maintain compressed subscription history and incrementally process analytics events, while a custom Apache Spark job generates initial Flink state from billions of historical events and supports validation and exports. A new Apache Pinot v2 query engine performs windowed aggregations and joins without offline preaggregation; most updates are processed in under one minute, nearly all reach users within 15 minutes, and production query latency is under 300 milliseconds. Metric-definition changes trigger historical recalculation while new events are buffered and later replayed, preserving a consistent Dashboard view during the transition.
Migrating to React Native's New Architecture
Shopify successfully migrated two largest apps, Shopify Mobile and Shopify Point of Sale, to React Native’s New Architecture while continuing weekly releases for millions of merchants. The strategy prioritized minimal code changes, dual-architecture compatibility, and performance and stability parity, with TopHat generating both architecture builds for every pull request. The team upgraded React Native first, updated or removed incompatible dependencies, and changed only native modules that failed under the new architecture rather than migrating all 40-plus modules to TurboModules. Migration issues included state batching, UIManager-related blank screens, shadow-tree manipulation, view flattening, and main-thread legacy module initialization; the reported outcome was maintained development velocity with no feature-development disruption, followed by planned optimization work.
Building production-ready agentic systems: Lessons from Shopify Sidekick
Shopify’s Sidekick evolved from a simple tool-calling system into an agentic assistant that helps merchants manage stores through natural language, exposing scaling challenges in architecture, evaluation, and training. As its inventory grew beyond 50 tools, the system prompt accumulated conflicting special cases and became difficult to maintain; JIT instructions instead return relevant guidance with tool data. For evaluation, the team uses Ground Truth Sets based on production distributions, human labels from at least three product experts, statistical agreement measures, specialized LLM judges calibrated against humans, and merchant simulation. Judge correlation rose from Cohen’s Kappa 0.02 to 0.61 against a human baseline of 0.69, while syntax validation improved from about 93% to 99% after reward-hacking fixes. GRPO training exposed opt-out, tag, and schema hacking, and the post recommends modularity, procedural plus semantic validation, user simulation, and iterative judge refinement for production agentic systems.
From naive webhooks to durable sync: Queue-based and event-driven data reconciliation patterns
Maintaining consistent product data between an internal catalog and Stripe becomes difficult when outages, throttling, high volumes, and changes from both systems create reconciliation failures. The post compares a naive one-way flow, in which a Lambda calls the Stripe API with no persistent synchronization record, with a queue-based design that durably stores changes, controls processing rate, retries failures with exponential backoff, and sends persistent failures to dead-letter queues. For bidirectional synchronization, it contrasts periodic ETL, using extraction, transformation, and loading, with an event-driven model based on Stripe Event Destinations, EventBridge, SQS, and symmetrical events from internal systems. The conclusion is that durable, observable queues and event-driven processing provide buffering, auditability, near-real-time propagation, independent change processing, and more graceful scaling for distributed reconciliation.
Keeping product data aligned with Stripe as your systems scale
Keeping internal product data aligned with Stripe becomes an architectural challenge as catalogs grow from hundreds to millions of items. The problem spans independently operated systems with different data models, API constraints, rate limits, availability guarantees, and consistency models, while products may change faster than periodic reconciliation can complete. Stripe's payment-focused model covers identifiers, descriptions, prices, currencies, billing terms, and subscription behavior, whereas internal systems may contain categories, inventory, rich content, technical specifications, media, and sensitive cost data. The series examines manual verification, simple scripts, and periodic jobs for smaller catalogs, then points to streaming, change data capture, intelligent partitioning, and conflict resolution for high-scale reconciliation. It concludes that cross-system synchronization requires deliberate mapping and automated architecture because perfect synchronization is difficult to guarantee in eventually consistent distributed systems.
Guardrails for money movement: Integrating Stripe MCP with Portia AI
Portia AI presents a customer-refund agent that combines its guardrails with Stripe’s official Model Context Protocol server. The agent reads a refund request, compares it with a policy file, identifies the relevant Stripe customer and payment intent, and evaluates whether the request should be approved. Portia’s planner produces a multi-agent plan, while execution agents run it and persist outputs in plan state; an execution hook pauses before the Stripe create-refund call. A clarification presents the request and the agent’s rationale to a human, who can approve it in the CLI; approval allows the refund to proceed, while rejection exits without creating one. The example also handles Gmail OAuth and can send the customer an email describing the outcome.
How we built it: Jurisdiction resolution for Stripe Tax
Stripe Tax’s jurisdiction resolution system (JRS) determines which US taxing jurisdictions apply to a transaction, a difficult task because more than 16,000 combinations of rates and rules depend on intricate, changing boundaries. Its offline geographic information system cleans and standardizes boundary data, overlays states, counties, cities, and districts, and generates time-aware Stripe places of taxation (SPOTs), while the online system matches an address to the relevant SPOT. To reduce point-in-polygon latency, JRS indexes nested bounding boxes in a balanced R-tree rebuilt with the Sort-Tile-Recursive algorithm, narrowing candidates before applying the final polygon calculation; disjoint SPOTs are split and smaller boxes prioritized. Most states achieve address matching in a few milliseconds, with 95th-percentile latency below 10 milliseconds except South Carolina, while historical SPOT data creates an ongoing memory challenge.
Stay within limits: API rate-limit-friendly pattern for Stripe webhooks
Stripe webhook handlers that treat events as signals and fetch the latest resource can preserve correctness when payloads are stale, partial, duplicated, or out of order, but bursts of events can drive excessive API traffic. The post describes Stripe’s general limit as 100 read requests per second and notes that exceeding it produces 429 responses. Its solution places Hookdeck Event Gateway between Stripe and the application: Hookdeck authenticates and queues incoming webhooks, throttles delivery, and lets the handler retrieve the current Stripe resource at a controlled pace. The Express.js flow verifies the Hookdeck signature, checks the event and resource ID, fetches the invoice with the Stripe SDK, and supports queue monitoring, alerts, and retries for backpressure.
Implementing scalable metered billing with Stripe: How Edgee handles billions of events
Edgee needed usage-based billing for a business combining flat-rate subscriptions with charges for proxy requests and delivered data events, while processing billions of monthly requests across more than 100 edge locations. Its architecture captures web data at the edge through a proxy and records raw metering data centrally in Google BigQuery. To control several terabytes of data, Edgee aggregates usage by tenant and sends hourly Stripe meter events through AWS Lambda, with graduated pricing and idempotency handled by Stripe. A Go configuration defines meters, prices, flat-rate plans, and pricing tiers, while retry logic and idempotent updates support resilience during disruptions. The resulting billing system remains stateless and low-latency while providing accurate monthly invoicing and a simple hosted customer interface.
Resilient Import Maps - Better Theme Development and Beyond
Shopify found that JavaScript modules and import maps failed in themes and App Blocks when modules loaded before a map, or when multiple maps collided. These restrictions reflected the requirement that module resolution remain stable, but real pages assembled by themes, apps, Shopify, and extensions could not reliably guarantee ordering or a single map. Working with web-platform contributors, Shopify proposed a reconciliation mechanism with one global import map, a resolved module set, and merging rules that preserve existing resolutions and drop conflicting or unsafe additions. The change reached the HTML specification and shipped in Chromium and WebKit; Chrome supports it from version 133 and Safari from 18.4. Shopify also uses es-modules-shim support for browsers without native support, while Firefox support is hoped for.
Introducing Stripe Workflows: Tailoring Payments to Your Business Needs
Stripe introduces Stripe Workflows, a Dashboard-based system for orchestrating Stripe products and APIs through responsive, end-to-end automation. It addresses the complexity of coordinating multiple Stripe products by replacing custom event-handling and dependency-management code with visual workflows that support real-time triggers, branching logic, dynamic fields, and more than 600 event triggers. Workflows includes execution monitoring with event-payload and step-level tracing, 30-day default log retention, exponential-backoff retries, built-in idempotency, and recursion protection capped at a depth of five. The post describes applications including reducing chargeback risk, routing high-value transactions for compliance review, and creating custom-priced subscriptions from finalized quotes without additional infrastructure.
Introducing Stripe's new public preview release channel
Stripe announces its new public preview release channel, which provides early access to API features before their General Availability launches. Preview features are described as operationally stable and production-ready, but they may receive breaking changes more often than GA features and may have geographic, onboarding, or approval restrictions. Each preview uses a distinct API version ending in preview, such as 2025-04-30.preview, selected through the Stripe-Version header; preview versions also appear in the API reference and changelog. Beta SDKs will use these preview versions and include preview features, with releases differentiated from GA counterparts by suffixes such as 5.2.0-beta.1. The example shows that a feature released only in preview is rejected by a GA version, requiring an explicit version change before use; this separation lets teams integrate earlier and provide feedback while avoiding unintended adoption of features with known restrictions.
Because nobody likes being charged twice
Payment workflows can produce duplicate charges when a customer retries after a connection drop while the backend is still retrying the original request. The post frames network timeouts, crashes, database locks, downstream errors, and user interruptions as normal distributed-systems failures that can leave payment state uncertain. It recommends generating a unique idempotency key for one specific action, sending it with the Stripe request, and reusing it on every retry; Stripe recognizes the key for 24 hours and returns the original response. It also recommends placing payment jobs in a queue such as Amazon SQS, where workers retry failures and route repeatedly failing messages to a dead-letter queue. Together, queues preserve work during temporary outages and idempotency makes retries safe, while careful key scope and timing avoid stale or cross-operation behavior.
Using an AWS microservice architecture for subscription management
Enterprise subscription management must handle mid-cycle plan changes, usage-based billing adjustments, synchronized service updates, atomicity, failed operations, data consistency, and auditability beyond basic recurring billing. This sample architecture uses an event-driven AWS design in which subscription changes are published to EventBridge and routed to Step Functions workflows. EventBridge provides at-least-once delivery, content-based filtering, dead-letter queue support, and integration with Step Functions, while Lambda functions validate changes, calculate Stripe proration, update external subscriptions, and trigger service-specific actions. Step Functions supplies retries with exponential backoff for StripeTemporaryError, DynamoDB stores current and historical subscription data using transactional updates, and Stripe calls use an event identifier as an idempotency key. The pattern is presented as a flexible foundation for reliability, maintainability, compensation for partial changes, and auditability in systems handling financial transactions and service provisioning.
Scaling Nextdoor’s Datastores: Part 4
Look-aside caching systems can become inconsistent when concurrent database updates execute cache writes out of order, allowing stale data to overwrite newer modifications. To prevent these racing writes, Nextdoor introduced a unique, monotonic db_version column to Postgres tables using database triggers that initialize version numbers on insert and increment them on update. Application updates retrieve this new version inside a transaction block and attach it as a metadata header to serialized cache values. Redis then executes custom Lua scripts, specifically set_if_version and del_if_version, to perform atomic conditional updates that reject any incoming payload with a version lower than or equal to the stored version. This serializable check ensures that out-of-order writes are dropped and the cache remains strictly aligned with the latest database state.
Load balancing Stripe API calls from multiple AWS regions
The guide describes a multi-region payment-processing architecture for applications that use Stripe’s API and need resilience against regional outages, latency, rate limits, and payment-data compliance constraints. It routes requests with Amazon Route 53 health checks and configurable latency-based, weighted, or geolocation policies, while identical regional API Gateway and Lambda deployments process payments. DynamoDB Global Tables replicate payment state and support distributed rate limiting, with optimistic locking, regional token-bucket allocation, retries, and exponential backoff for Stripe requests. The sample Lambda records a payment as PENDING, creates and confirms a Stripe PaymentIntent, then updates the state with the Stripe payment ID and returned status; the conclusion presents the design as a foundation for regional resilience, state consistency, and API-rate management.
Securing Stripe API Keys in AWS with automatic rotation
The article presents a production-grade approach to securing Stripe API keys in AWS, motivated by the risks and operational limits of basic secret storage for payment processing. It compares AWS Parameter Store with Secrets Manager, emphasizing built-in rotation, CloudTrail audit trails, IAM integration, larger secrets, and cross-account access despite higher cost. The implementation uses environment-specific secret paths, tags, and IAM conditions to isolate development, staging, and production credentials, with separate rotation schedules. For zero-downtime rotation, applications refresh cached credentials after authentication failures while both old and new keys remain valid during a transition. The design also covers CloudWatch monitoring, emergency rotation procedures, cross-region replication, region-specific schedules, and cost considerations, concluding that ongoing review is necessary for secure and reliable payment operations.
Related topics
All topics →Weekly digest
The best engineering reads, once a week.