---
title: "High Availability"
description: "12 posts about High Availability, summarised, each linking to the original."
---

# High Availability
> 12 posts about High Availability, summarised, each linking to the original.

## Articles

### [Intelligent Workload Management: Keeping Your Clusters Available When It Matters](https://yomu.fyi/post/intelligent-workload-management-keeping-your-clusters-available-when-i.md)
- Company: [MongoDB](https://yomu.fyi/company/mongodb.md)
- Published: Oct 7, 2026
- Type: Announcement

MongoDB Atlas announced Intelligent Workload Management (IWM) as GA in MongoDB 9.0, a managed availability capability that keeps clusters responsive and predictable under overload. When demand exceeds safe processing, IWM limits incoming work and queues surplus requests by default, keeps short-running operations moving while managing long-running ones conservatively, and adjusts memory and cache management to preserve cluster health. It works with or without auto-scaling, helping clusters stay stable while additional capacity provisions, closing the gap between a traffic spike and new capacity coming online. Default protections are enabled at no extra cost on eligible dedicated clusters and require no application changes; optional Load Shedding can reject excess operations for sustained overload, and Coinbase’s VP of Engineering cited confidence during peak trading windows. Observability metrics in Atlas track IWM interventions, and a test validates driver compatibility and application handling before enabling Load Shedding in production.


### [Scale without limits: Multigres, OrioleDB, and dbarena](https://yomu.fyi/post/scale-without-limits-multigres-orioledb-and-dbarena.md)
- Company: [Supabase](https://yomu.fyi/company/supabase.md)
- Author: joe\_sciarrino, alexander\_korotkov, daniel\_mitterdorfer, aditya\_maruvada
- Published: Oct 2, 2026
- Type: Announcement

At Supabase Select, Supabase announced Multigres for high availability and connection pooling, OrioleDB for high performance storage, and dbarena for transparent benchmarking. Multigres is an open source operating system for Postgres that adds scalable connection pooling and automated multi-node failover using a consensus protocol built on synchronous replication, preventing data loss during failover. OrioleDB replaces Postgres’s heap storage with an undo log-based engine that eliminates bloat, VACUUM overhead, and transaction ID wraparound by using 64-bit transaction IDs, delivering up to 1.8x higher throughput in TPC-C-derived benchmarks. dbarena.com is an open benchmarks site that publishes reproducible performance and cost comparisons across managed Postgres providers including Supabase, Amazon RDS, and Google Cloud SQL, with full methodology and raw data. These tools aim to remove scaling limitations at every layer of Postgres, with all improvements being open source and available to the community.


### [Matching OpenShift edge topologies to your physical footprint](https://yomu.fyi/post/matching-openshift-edge-topologies-to-your-physical-footprint.md)
- Company: [Red Hat](https://yomu.fyi/company/red-hat.md)
- Author: Daniel Froehlich
- Published: Sep 18, 2026
- Type: Explainer

Red Hat OpenShift topologies are mapped to edge-site constraints such as hardware footprint, availability, rack space, power, and workload needs. It is presented as a micro cloud that brings full Kubernetes functionality to server-class edge hardware, with optional virtualization and software-defined storage. Cluster capabilities can be minimized with baselineCapabilitySet: none and selectively enabled later, although added capabilities cannot be removed without reinstalling. Options span single-node OpenShift, which requires 4 vCPUs, 16 GB RAM, and 120 GB storage, two-node designs using fencing or an arbiter, and three-node compact clusters for resilient high availability. Each topology retains shared management and security practices, so selection depends on the physical footprint, failure tolerance, and scale required at the site.


### [Benchmark Shows MongoDB Atlas Manages Thousands of Payments Per Second with Zero Data Loss](https://yomu.fyi/post/benchmark-shows-mongodb-atlas-manages-thousands-of-payments-per-second.md)
- Company: [MongoDB](https://yomu.fyi/company/mongodb.md)
- Published: Sep 9, 2026
- Type: Benchmark

A benchmark of the Icon Payments Framework (IPF), trusted by Citi, NatWest, and BNP Paribas, on MongoDB Atlas demonstrated extreme performance and resilience for instant payment processing. The system sustained 6,000 end-to-end payments per second, requiring approximately 430,000 simultaneous database operations, with a mean end-to-end latency of 0.51 seconds and persistence latency below 30 milliseconds. Upgrading from MongoDB Atlas 8.0 to 8.3 reduced persistence latency by roughly 50%, from 40 to 20 milliseconds at 4,000 payments per second, and throughput scaled near-linearly across the 500 to 6,000 range while latency remained flat until peak and hot-shard CPU utilization sat at about half. During a primary failover, a new node was elected in five seconds with zero data loss and no application restart. An application node failure recovered to 3,500 transactions per second in 90 seconds with zero data loss.


### [Reference architecture for HA scanning with Red Hat Advanced Cluster Security for Kubernetes](https://yomu.fyi/post/reference-architecture-for-ha-scanning-with-red-hat-advanced-cluster-s.md)
- Company: [Red Hat](https://yomu.fyi/company/red-hat.md)
- Author: Johannes Malsam
- Published: Sep 7, 2026
- Type: Problem & solution

Red Hat Advanced Cluster Security for Kubernetes exposes an image-scanning API through Central, but upgrades and restarts can interrupt CI/CD pipelines. The reference architecture uses two independent Central Service instances—primary and failover—with separate databases, scanner deployments, and namespaces, plus a client-side script that probes the primary’s health endpoint before each scan and falls back when needed. Operators install the failover instance, duplicate image registry integrations and build-time policies, configure CI authentication, and pause reconciliation on the failover Central custom resource while upgrading the primary, then resume it to upgrade the second instance. This avoids scan API unavailability during the staged upgrade process, but failover caches are cold, requiring temporarily longer scans and additional registry traffic. The instances do not synchronize databases, caches, configuration, or vulnerability updates, and the design does not provide general-purpose HA for secured cluster services or delegated scanning.


### [How Palo Alto Networks Built a Zero](https://yomu.fyi/post/how-palo-alto-networks-built-a-zero.md)
- Company: [MongoDB](https://yomu.fyi/company/mongodb.md)
- Published: Aug 17, 2026
- Type: Problem & solution

Palo Alto Networks built a new SASE Health Portal to provide real-time service health visibility for its enterprise customers. The previous architecture relied on relational databases and cloud data warehousing, which caused schema migration bottlenecks and regional lock-in. To solve this, the team deployed containerized services across multiple cloud zones in an active-active configuration. They used MongoDB Atlas as a globally replicated database, enabling automated cross-region failover and flexible document modeling for customer subscriptions. The new portal eliminates alert fatigue by allowing granular subscriptions and achieves zero relational joins for fast incident matching.


### [Zone-Failure-Resilient OpenSearch® at Uber](https://yomu.fyi/post/zone-failure-resilient-opensearch-at-uber.md)
- Company: [Uber](https://yomu.fyi/company/uber.md)
- Published: Jul 21, 2026
- Type: Problem & solution

Uber describes how it made OpenSearch deployments zone-failure resilient so querying and ingestion remain available after a complete zone loss. The design combines OpenSearch’s shard-allocation awareness with Odin-based isolation groups that distribute nodes predictably across failure domains and balance roles. Clusters maintain at least three shard copies across three isolation groups, while forced awareness keeps shards for a missing group unassigned instead of triggering heavy rebalancing; this trades immediate full replication for stability in surviving zones. For manager resiliency, five cluster manager nodes and cluster.auto\_shrink\_voting\_configuration allow quorum after a zone failure plus one additional manager failure. Uber reports that isolation groups replaced uneven physical zone IDs, enabling complete shard assignment, preventing disk skew and hot nodes, and supporting green cluster health.


### [Modernizing Artifact Storage at Uber](https://yomu.fyi/post/modernizing-artifact-storage-at-uber.md)
- Company: [Uber](https://yomu.fyi/company/uber.md)
- Published: May 28, 2026
- Type: Problem & solution

Uber’s legacy artifact platform used two five-node clusters with local disks, asynchronous replication, and GeoDNS failover to support builds across monorepos and microrepos. As artifact volume grew, limited node capacity, inconsistent replication, manual hardware evacuation, and risky multi-terabyte upgrades created operational and data-loss risks. Uber moved to a managed SaaS platform with multi-region availability, cross-region replication, and cloud-native blob storage, then added an internal validation proxy in front of it. The proxy uses MySQL metadata and conditional requests, including If-None-Match and If-Modified-Since, to validate artifacts against the SaaS origin while reusing unchanged bytes; failures can fall back to passthrough, preserving correctness at higher latency and egress cost. The design reduced operational risk, improved observability, and made artifact delivery more cost-efficient at scale.


### [How We Built Fly Postgres](https://yomu.fyi/post/how-we-built-fly-postgres.md)
- Company: [Fly.io](https://yomu.fyi/company/fly-io.md)
- Published: Nov 29, 2022
- Type: Explainer

Fly.io describes how it built Fly Postgres as an automated database app rather than a managed database service. After initially resisting durable storage and database work, the company added attached disk storage and designed a deployable Postgres application with convenience commands, using Postgres streaming replication, Stolon, and Consul to support high availability. A two-node cluster can designate a writable leader and asynchronous standby, while Stolon’s sentinels, keepers, and proxies coordinate state, elect a replacement leader, and route connections; Consul introduces an additional failure mode. Backups use point-in-time, block-level snapshots of the volume, a platform capability that can also support other file-system databases. The post concludes that automated Postgres serves many apps, while managed database partnerships may suit users seeking a simpler experience.


### [Building and Scaling a Global Chatbot using Heroku + Terraform](https://yomu.fyi/post/building-and-scaling-a-global-chatbot-using-heroku-terraform.md)
- Company: [Heroku](https://yomu.fyi/company/heroku.md)
- Author: Garen Torikian
- Published: Apr 22, 2020
- Type: Problem & solution

Live Agent, Salesforce’s embeddable chatbot, must handle customer interactions and requests at global scale while remaining highly available across regions. Its eight-person team chose Heroku to avoid managing bare metal, cloud virtual machines, databases, and other third-party services, while relying on managed Java support and regional infrastructure. The platform runs ten apps with Heroku Postgres, Redis, and Apache Kafka dependencies, and deploys them inside Heroku Private Spaces to isolate network boundaries and data. Terraform defines and replicates apps, add-ons, custom domains, logging, and profiling configuration across regions, allowing changes to propagate through a pull request. The result described is a simpler operational model in which Heroku handles maintenance and the team can scale the same architecture into new geographic locations.


### [How Heroku Operates its Multi-Tenant Apache Kafka Services](https://yomu.fyi/post/how-heroku-operates-its-multi-tenant-apache-kafka-services.md)
- Company: [Heroku](https://yomu.fyi/company/heroku.md)
- Author: Ali Hamidi
- Published: Jul 11, 2019
- Type: Explainer

Heroku’s Apache Kafka service supports thousands of developers and millions of transactions, including customers sharing multi-tenant clusters. The post explains how those clusters provide security, predictable performance, availability, and production-like topology at lower cost than single-tenant plans. Multi-tenant and single-tenant offerings use the same numbers of brokers and ZooKeeper nodes, while Kafka ACLs, per-tenant resource namespaces, and producer/consumer byte quotas isolate customers and limit resource contention. Heroku provisions purchased resources, expands storage at 80% of quota, and uses higher defaults for partitions, replicas, and in-sync replicas; exceeding capacity can eventually throttle throughput without stopping the cluster. Automated tests model 50 users with varied traffic, exercise throughput and partition configurations, and simulate broker failures and restarts to identify operational limits and adjust the infrastructure before customer impact.


### [Rolling the Heroku Redis Fleet](https://yomu.fyi/post/rolling-the-heroku-redis-fleet.md)
- Company: [Heroku](https://yomu.fyi/company/heroku.md)
- Author: Camille Baldock
- Published: Jun 27, 2018
- Type: Explainer

Heroku proactively rolled its Redis fleet to a version not vulnerable to CVE-2018-11218 during an embargo, aiming to protect customers while limiting disruption and downtime. The operation relied on immutable infrastructure: engineers built, tested, reviewed, and released a new server image, then replaced High Availability standbys before scheduling customer maintenance. During each update, the team verified replication, broke the link so the standby could accept writes, redirected application config vars to the new primary, de-provisioned the old primary, and created a replacement standby. Automation controlled concurrency and limited replacement work to the on-call operator’s business hours, while customers received advance and completion emails. The fleet roll covered all Heroku Redis customers within five weeks of notification and finished one week before the public announcement; the process also applies to Heroku Postgres and Apache Kafka on Heroku.