# How They Scaled

> How They Scaled (https://howtheyscaled.com) is a free, searchable index of 73 real "how we scaled" engineering write-ups from 26 companies (e.g. OpenAI, Discord, Shopify, Figma, Stripe), tagged by stack, technique and company. Each entry has a short summary in our own words, scale numbers only when the source states them, and a link to the original post.

## Key pages
- [Home / search](https://howtheyscaled.com/): all stories, filterable by stack, technique, company and scale
- [All topics](https://howtheyscaled.com/topics/): 87 topic pages (tech, techniques, companies)
- [About: sources and method](https://howtheyscaled.com/about/)
- [Newsletter](https://howtheyscaled.com/newsletter)
- [Sponsor](https://howtheyscaled.com/sponsor)
- [All stories as JSON](https://howtheyscaled.com/stories.json)
- [Sitemap](https://howtheyscaled.com/sitemap.xml)

## Tech & stack
- [How teams scaled PostgreSQL: 14 real case studies](https://howtheyscaled.com/tech/postgresql/)
- [How teams scaled Rust: 11 real case studies](https://howtheyscaled.com/tech/rust/)
- [How teams scaled MySQL: 10 real case studies](https://howtheyscaled.com/tech/mysql/)
- [How teams scaled Go: 7 real case studies](https://howtheyscaled.com/tech/go/)
- [How teams scaled Kafka: 7 real case studies](https://howtheyscaled.com/tech/kafka/)
- [How teams scaled Ruby on Rails: 5 real case studies](https://howtheyscaled.com/tech/ruby-on-rails/)
- [How teams scaled AWS RDS: 4 real case studies](https://howtheyscaled.com/tech/aws-rds/)
- [How teams scaled Java: 4 real case studies](https://howtheyscaled.com/tech/java/)
- [How teams scaled Kubernetes: 4 real case studies](https://howtheyscaled.com/tech/kubernetes/)
- [How teams scaled Python: 4 real case studies](https://howtheyscaled.com/tech/python/)
- [How teams scaled SQLite: 4 real case studies](https://howtheyscaled.com/tech/sqlite/)
- [How teams scaled Vitess: 4 real case studies](https://howtheyscaled.com/tech/vitess/)
- [How teams scaled Cassandra: 3 real case studies](https://howtheyscaled.com/tech/cassandra/)
- [How teams scaled GPUs: 3 real case studies](https://howtheyscaled.com/tech/gpus/)
- [How teams scaled MongoDB: 3 real case studies](https://howtheyscaled.com/tech/mongodb/)
- [How teams scaled PgBouncer: 3 real case studies](https://howtheyscaled.com/tech/pgbouncer/)
- [How teams scaled Redis: 3 real case studies](https://howtheyscaled.com/tech/redis/)
- [How teams scaled RocksDB: 3 real case studies](https://howtheyscaled.com/tech/rocksdb/)
- [How teams scaled Amazon S3: 2 real case studies](https://howtheyscaled.com/tech/amazon-s3/)
- [How teams scaled Azure: 2 real case studies](https://howtheyscaled.com/tech/azure/)
- [How teams scaled Azure Blob Storage: 2 real case studies](https://howtheyscaled.com/tech/azure-blob-storage/)
- [How teams scaled ClickHouse: 2 real case studies](https://howtheyscaled.com/tech/clickhouse/)
- [How teams scaled Cosmos DB: 2 real case studies](https://howtheyscaled.com/tech/cosmos-db/)
- [How teams built custom storage at scale: 2 real case studies](https://howtheyscaled.com/tech/custom-storage/)
- [How teams scaled Elasticsearch: 2 real case studies](https://howtheyscaled.com/tech/elasticsearch/)
- [How teams scaled Elixir: 2 real case studies](https://howtheyscaled.com/tech/elixir/)
- [How teams scaled Envoy: 2 real case studies](https://howtheyscaled.com/tech/envoy/)
- [How teams scaled Git: 2 real case studies](https://howtheyscaled.com/tech/git/)
- [How teams scaled Nginx: 2 real case studies](https://howtheyscaled.com/tech/nginx/)
- [How teams scaled on object storage: 2 real case studies](https://howtheyscaled.com/tech/object-storage/)
- [How teams scaled PyTorch: 2 real case studies](https://howtheyscaled.com/tech/pytorch/)
- [How teams scaled ScyllaDB: 2 real case studies](https://howtheyscaled.com/tech/scylladb/)
- [How teams scaled Spokes: 2 real case studies](https://howtheyscaled.com/tech/spokes/)
- [How teams scaled WebSockets: 2 real case studies](https://howtheyscaled.com/tech/websockets/)
- [How teams scaled ZooKeeper: 2 real case studies](https://howtheyscaled.com/tech/zookeeper/)

## Techniques
- [Caching: 8 real scaling case studies](https://howtheyscaled.com/technique/caching/)
- [Database migration: 7 real scaling case studies](https://howtheyscaled.com/technique/database-migration/)
- [Horizontal sharding: 6 real scaling case studies](https://howtheyscaled.com/technique/horizontal-sharding/)
- [Read replicas: 6 real scaling case studies](https://howtheyscaled.com/technique/read-replicas/)
- [Rewrite: 6 real scaling case studies](https://howtheyscaled.com/technique/rewrite/)
- [Connection pooling: 5 real scaling case studies](https://howtheyscaled.com/technique/connection-pooling/)
- [Multi-tenancy: 5 real scaling case studies](https://howtheyscaled.com/technique/multi-tenancy/)
- [Online migration: 5 real scaling case studies](https://howtheyscaled.com/technique/online-migration/)
- [Fan-out: 4 real scaling case studies](https://howtheyscaled.com/technique/fan-out/)
- [Load balancing: 4 real scaling case studies](https://howtheyscaled.com/technique/load-balancing/)
- [Load shedding: 4 real scaling case studies](https://howtheyscaled.com/technique/load-shedding/)
- [Query optimization: 4 real scaling case studies](https://howtheyscaled.com/technique/query-optimization/)
- [Replication: 4 real scaling case studies](https://howtheyscaled.com/technique/replication/)
- [Sharding: 4 real scaling case studies](https://howtheyscaled.com/technique/sharding/)
- [Zero downtime: 4 real scaling case studies](https://howtheyscaled.com/technique/zero-downtime/)
- [Benchmarking: 3 real scaling case studies](https://howtheyscaled.com/technique/benchmarking/)
- [Change data capture: 3 real scaling case studies](https://howtheyscaled.com/technique/change-data-capture/)
- [Columnar storage: 3 real scaling case studies](https://howtheyscaled.com/technique/columnar-storage/)
- [Distributed training: 3 real scaling case studies](https://howtheyscaled.com/technique/distributed-training/)
- [Partitioning: 3 real scaling case studies](https://howtheyscaled.com/technique/partitioning/)
- [Queues: 3 real scaling case studies](https://howtheyscaled.com/technique/queues/)
- [Rate limiting: 3 real scaling case studies](https://howtheyscaled.com/technique/rate-limiting/)
- [Tiered storage: 3 real scaling case studies](https://howtheyscaled.com/technique/tiered-storage/)
- [Vertical partitioning: 3 real scaling case studies](https://howtheyscaled.com/technique/vertical-partitioning/)
- [Capacity planning: 2 real scaling case studies](https://howtheyscaled.com/technique/capacity-planning/)
- [Consistent hashing: 2 real scaling case studies](https://howtheyscaled.com/technique/consistent-hashing/)
- [Control plane separation: 2 real scaling case studies](https://howtheyscaled.com/technique/control-plane-separation/)
- [Cost optimization: 2 real scaling case studies](https://howtheyscaled.com/technique/cost-optimization/)
- [Dual writes: 2 real scaling case studies](https://howtheyscaled.com/technique/dual-writes/)
- [Edge computing: 2 real scaling case studies](https://howtheyscaled.com/technique/edge-computing/)
- [Erasure coding: 2 real scaling case studies](https://howtheyscaled.com/technique/erasure-coding/)
- [Hardware reliability: 2 real scaling case studies](https://howtheyscaled.com/technique/hardware-reliability/)
- [Indexing: 2 real scaling case studies](https://howtheyscaled.com/technique/indexing/)
- [Load testing: 2 real scaling case studies](https://howtheyscaled.com/technique/load-testing/)
- [Networking: 2 real scaling case studies](https://howtheyscaled.com/technique/networking/)
- [Storage/compute separation: 2 real scaling case studies](https://howtheyscaled.com/technique/storage-compute-separation/)
- [Workload isolation: 2 real scaling case studies](https://howtheyscaled.com/technique/workload-isolation/)

## Companies
- [Meta architecture: how Meta scaled (7 case studies)](https://howtheyscaled.com/company/meta/)
- [Datadog architecture: how Datadog scaled (6 case studies)](https://howtheyscaled.com/company/datadog/)
- [Discord architecture: how Discord scaled (6 case studies)](https://howtheyscaled.com/company/discord/)
- [Shopify architecture: how Shopify scaled (6 case studies)](https://howtheyscaled.com/company/shopify/)
- [Cloudflare architecture: how Cloudflare scaled (5 case studies)](https://howtheyscaled.com/company/cloudflare/)
- [GitHub architecture: how GitHub scaled (5 case studies)](https://howtheyscaled.com/company/github/)
- [Dropbox architecture: how Dropbox scaled (4 case studies)](https://howtheyscaled.com/company/dropbox/)
- [Figma architecture: how Figma scaled (4 case studies)](https://howtheyscaled.com/company/figma/)
- [Notion architecture: how Notion scaled (4 case studies)](https://howtheyscaled.com/company/notion/)
- [OpenAI architecture: how OpenAI scaled (3 case studies)](https://howtheyscaled.com/company/openai/)
- [Slack architecture: how Slack scaled (3 case studies)](https://howtheyscaled.com/company/slack/)
- [Stripe architecture: how Stripe scaled (3 case studies)](https://howtheyscaled.com/company/stripe/)
- [GitLab architecture: how GitLab scaled (2 case studies)](https://howtheyscaled.com/company/gitlab/)
- [LinkedIn architecture: how LinkedIn scaled (2 case studies)](https://howtheyscaled.com/company/linkedin/)
- [PlanetScale architecture: how PlanetScale scaled (2 case studies)](https://howtheyscaled.com/company/planetscale/)

## Comparisons
- [Cassandra vs ScyllaDB at scale: why Discord switched](https://howtheyscaled.com/compare/cassandra-vs-scylladb/): The clearest real-world comparison is Discord. It moved messages from MongoDB to Cassandra in 2017, then moved its message store from Cassandra to ScyllaDB and put Rust data services in front that coalesce requests for hot partitions, at trillions of messages. Discord's post describes ScyllaDB as Cassandra-compatible and written in C++, with no garbage collector, after years of JVM garbage-collection pauses on Cassandra.
- [MongoDB vs Cassandra at scale: Discord's switch and Stripe's path](https://howtheyscaled.com/compare/mongodb-vs-cassandra/): Discord is the direct comparison: its 2017 post explains outgrowing MongoDB and moving messages to Cassandra with a partition key of channel plus time bucket, at billions of messages and 120 million messages a day. Stripe shows the other path: it stayed on document databases (MongoDB, then its own DocDB) and invested in zero-downtime migrations between shards, citing 1.5 PB and 99.999% uptime.
- [Go vs Rust for backend services at scale: what real teams chose](https://howtheyscaled.com/compare/go-vs-rust/): The best-known direct comparison is Discord's 2020 post: it rewrote its Read States service from Go to Rust to get rid of garbage-collection latency spikes in a large in-memory cache. Elsewhere in our database the two languages coexist: Dropbox lists both Rust and Go for Magic Pocket, Datadog built Husky in Go and redid timeseries indexing in Rust, and Cloudflare uses Go for Quicksilver and its HTTP analytics pipeline and Rust for Pingora.
- [Envoy vs Nginx at scale: why Dropbox and Cloudflare moved off Nginx](https://howtheyscaled.com/compare/envoy-vs-nginx/): Dropbox is the direct case: it moved its edge traffic proxy from Nginx to Envoy for better observability and extensibility. Cloudflare also moved off Nginx, but to Pingora, its own Rust proxy that reuses connections better and needs less CPU and memory, at 1 trillion requests a day. OpenAI uses Envoy for connection fan-in in its Habitat storage platform.
- [Redis vs MySQL at scale: why Shopify moved inventory to MySQL](https://howtheyscaled.com/compare/redis-vs-mysql/): Shopify's 2026 post is the direct comparison: it moved checkout inventory reservations from Redis to MySQL, using one row per sellable unit, a bounded pool of 1,000 rows per item and location, and SELECT ... FOR UPDATE SKIP LOCKED. The real ceiling turned out to be connections held by other checkout code. Elsewhere Redis plays supporting roles: Stripe's rate limiters and Stack Overflow's caching.
- [ClickHouse vs Postgres for analytics at scale: real examples](https://howtheyscaled.com/compare/clickhouse-vs-postgres/): Cloudflare's 2018 post is the direct case: it rebuilt its HTTP analytics pipeline on ClickHouse, replacing a Postgres/Citus setup, at 6M requests per second. Staying on Postgres for analytics-style data is possible too: Timescale scaled a 350 TB+ dataset (10 billion new records a day) on PostgreSQL with its TimescaleDB extension, using hypertables, columnar compression and tiered storage.
- [PostgreSQL vs MySQL at scale: how real companies scaled each](https://howtheyscaled.com/compare/postgresql-vs-mysql/): Both scale to very large workloads in our database. On PostgreSQL, OpenAI runs ChatGPT on a single primary with nearly 50 read replicas, and Figma and Notion sharded Postgres themselves (a custom query proxy at Figma, workspace-keyed logical shards at Notion). On MySQL, GitHub runs 5.5 million QPS across 50+ clusters, Slack (2.3 million QPS) and Shopify's Shop app shard with Vitess, and Meta's TAO caches a graph stored in sharded MySQL.
- [etcd vs SQLite for a control plane: Tailscale's migration](https://howtheyscaled.com/compare/etcd-vs-sqlite/): Tailscale's post is the direct comparison: it replaced etcd with SQLite plus Litestream replication for a simpler control-plane datastore. SQLite shows up at scale elsewhere too: Cloudflare's D1 manages millions of SQLite databases at the edge, and Notion caches data in the browser with WASM SQLite.
- [Aurora vs RDS Postgres: Atlassian's 4 million database migration](https://howtheyscaled.com/compare/aurora-vs-rds-postgres/): Atlassian's 2025 post is the direct case: it migrated about four million Jira databases from RDS Postgres to Aurora, balancing reliability, downtime and cost. Teams have also scaled a long way on RDS Postgres: Figma vertically partitioned and then horizontally sharded Postgres on RDS, and Notion sharded its Postgres monolith by workspace on RDS.
- [Sharding vs partitioning: real examples from Figma, GitHub and Notion](https://howtheyscaled.com/compare/sharding-vs-partitioning/): Partitioning splits data into smaller pieces; sharding is partitioning rows across separate database servers. In our database, vertical partitioning means moving whole table groups to their own database, as Figma, GitHub (schema domains) and GitLab (a separate CI database) did. Horizontal sharding splits rows of the same tables across servers, as Figma, Notion, Slack and Shopify did. Figma's posts show both in order: vertical partitioning (2023), then horizontal sharding (2024).
- [Read replicas vs sharding: how far replicas got OpenAI, and when teams sharded](https://howtheyscaled.com/compare/read-replicas-vs-sharding/): OpenAI is the strongest case for going far with replicas: ChatGPT runs on a single-primary Postgres with nearly 50 global read replicas, while write-heavy shardable workloads moved to Cosmos DB. Replicas scale reads, not writes, so the teams here whose writes outgrew one primary sharded instead: Figma, Notion, Slack and Shopify.
- [All comparisons](https://howtheyscaled.com/compare/)

## Tools
- [Postgres connection pool size calculator](https://howtheyscaled.com/tools/postgres-connection-calculator/): Free Postgres connection pool size calculator: (cores × 2) + spindles starting point, Little's law demand, max_connections headroom and PgBouncer pool math. Runs in your browser.

## Stories
- [OpenAI: Rapidly scaling online storage to serve over 1 billion ChatGPT users (Part II)](https://howtheyscaled.com/s/openai-rapidly-scaling-online-storage-to-serve-over-1-billion-chatgpt-users-part): OpenAI's Habitat storage platform went from one shared Azure Cosmos DB container, to dedicated single-tenant containers that pushed capacity planning onto every product team, and back to a shared container by default once Azure added hot-key throttling, request-priority QoS and a new serverless mode where each physical partition scales to 10K RU/s and splits on RU usage. After failover and failback outages in late 2024, OpenAI and Azure now co-own testing and monitoring. Replicating small latency-critical datasets widely, a Valkey lookaside cache invalidated through the Cosmos DB change feed, and a Rust rewrite of the proxy cut global read p50 from about 120 ms to about 10 ms.
- [Grab: App stability at scale with a layered defense](https://howtheyscaled.com/s/grab-app-stability-at-scale-with-a-layered-defense): With many engineers and AI-assisted code landing in a weekly release of a superapp that has millions of lines of Android code, Grab stops crashes in layers. Lint rules (including custom ones written after post-mortems) and tests block merges, a mandatory one-week Grab Early Access build catches crashes before production, and a staged rollout over a week is automatically paused when the new version's crash rate looks abnormal. In production, on-call engineers first flip feature flags, then try server-side fixes, then hotfix, helped by a flag-rollout history dashboard and Crashlytics data exported to BigQuery.
- [GitHub: The bridge to agent-scale Git infrastructure](https://howtheyscaled.com/s/github-the-bridge-to-agent-scale-git-infrastructure): GitHub has copied 99.99999% of its Git repositories to Azure, where most now keep two of their five replicas and Azure serves about half of Git traffic. The busiest remaining repositories were blocked by a ~25ms cross-region round trip, because Spokes held a repository-wide lock for each write while waiting on the slowest healthy replica. Scoping the quorum to individual Git references lets writes to different branches proceed in parallel (3-4x higher throughput in internal testing), and a virtual write replica that streams writes into Azure Blob Storage lets stateless read replicas scale out on demand.
- [Shopify: Cross-store product clustering across millions of stores](https://howtheyscaled.com/s/shopify-cross-store-product-clustering-across-millions-of-stores): Shopify groups the same real-world product sold by different merchants under one Universal Product Identifier. Embedding nearest-neighbor search finds plausible pairs across billions of listings, then three scorers of rising cost judge them: a CPU GBDT (L1) over trillions of pairs, a fine-tuned multilingual E5 cross-encoder (L2), and an image-aware reranker (L3) fed from prioritized GPU queues. A bounded union-find splits the graph into single-machine components, and HAC with a learned GBDT merge rule builds high-precision clusters daily, with an LLM judge validated against human labels supplying training data and cached scores reused between builds.
- [Meta: Inside Prometheus: Meta's Journey to a Gigawatt-Scale Supercluster](https://howtheyscaled.com/s/meta-inside-prometheus-meta-s-journey-to-a-gigawatt-scale-supercluster): Meta turned its New Albany, Ohio data center site from web traffic into Prometheus, a gigawatt-scale AI supercluster spanning multiple interconnected buildings that behaves as one machine. It runs NVL72 racks (Catalina on GB200 with 800G of scale-out per GPU, Clemente on GB300 in a single rack) on a dedicated Ethernet back-end network for GPU-to-GPU traffic. Reliability work pushed pre-training goodput above 85% and mean time between interruptions past 54K GPU hours, and the cluster is growing toward roughly 1 million GPUs.
- [Meta: 2026 World Cup: Breaking Records, Spiky Charts and Reliability at Scale](https://howtheyscaled.com/s/meta-2026-world-cup-breaking-records-spiky-charts-and-reliability-at-scale): How Meta absorbed the 2026 World Cup, when WhatsApp set a record of more than 30 million messages per second during the final. Pre-provisioned capacity buffers were the most effective lever, alongside country-level shedding of non-critical load, load-testing and resizing 100+ services, forecasting each region's peak separately, and no deploy freeze.
- [Netflix: TimeSeries Tiered Storage Journey: Kafka/Flink Streams to Native Cassandra Cold Reads](https://howtheyscaled.com/s/netflix-timeseries-tiered-storage-journey-kafka-flink-streams-to-native-cassandr): Netflix moved older data in its multi-petabyte TimeSeries Abstraction out of hot Cassandra storage in two steps. First, Kafka and Flink streamed events to S3 as Parquet files, which a daily job compacted into small, time-sorted row groups with Bloom filters cached in EVCache (p50 ~150 ms, p99 ~500 ms). The second design skips that streaming pipeline: a ReadOnlyCompactionStrategy aligns immutable SSTables to token ranges, and a custom pluggable Memtable (Cassandra 4.1) reads directly from existing Cassandra backups in S3. It now holds over 15 PB of compressed cold data, cut disk usage on affected clusters from 80% to 7%, and improved p90 latency by ~30%.
- [Meta: Meta's Generative Ads Model (GEM): Scaling the Central Model and Compute Engine for Frontier Ads AI](https://howtheyscaled.com/s/meta-meta-s-generative-ads-model-gem-scaling-the-central-model-and-compute-engin): Meta replaced separate per-surface ad prediction systems with GEM, one central recommendation foundation model trained across all of its ad surfaces. A new LLM-style architecture (Kunlun) showed LLM-like scaling with 2.5x more model complexity, while custom low-precision kernels and 5D parallelism doubled end-to-end training efficiency to 20-25% MFU at 4x the training FLOPs across thousands of GPUs. Post-training transfer (LoopFM) and elastic pre-computation (Solaris) pass GEM's gains to real-time serving models without extra latency.
- [Cloudflare: Under the hood, off the hot path: how D1 scales to millions of databases](https://howtheyscaled.com/s/cloudflare-under-the-hood-off-the-hot-path-how-d1-scales-to-millions-of-database): How Cloudflare's D1 keeps query execution at the edge while a separate control plane manages millions of SQLite databases.
- [Meta: Shipping Media Over QUIC at Meta Scale for Instagram Live Ingest](https://howtheyscaled.com/s/meta-shipping-media-over-quic-at-meta-scale-for-instagram-live-ingest): Instagram Live ingest moved from Meta's in-house RUSH protocol to the open IETF Media over QUIC standard on iOS and Android. Edge endpoints translate MoQ frames into the RUSH format, so the backend did not change. Server-side routing let the experiment resize in minutes, the transport falls back to TCP when UDP is blocked, and the launch matched RUSH on quality and reliability.
- [GitHub: Building Git infrastructure for agent-scale development](https://howtheyscaled.com/s/github-building-git-infrastructure-for-agent-scale-development): GitHub explains why agent workloads strain Spokes, which keeps five durable copies of each repo on fileserver disks, so every added read replica slows writes. The new design coordinates only the ref update, moves compaction and GC to separate workers, and separates storage from compute: Azure Blob Storage holds the authoritative data while lightweight caching workers serve reads.
- [OpenAI: Rapidly scaling online storage to serve over 1 billion ChatGPT users](https://howtheyscaled.com/s/openai-rapidly-scaling-online-storage-to-serve-over-1-billion-chatgpt-users): OpenAI's Habitat storage platform grew from a Python client library over Cosmos DB into a central service handling 70M+ requests per second. The team ran many low-concurrency Python processes to keep asyncio delay down, switched aiohttp connection reuse from LIFO to FIFO to stop a metastable failure, used Envoy for connection fan-in, kept a deliberately simple NoSQL API, then rewrote the service in Rust.
- [PlanetScale: 118 million queries per second on Neki](https://howtheyscaled.com/s/planetscale-118-million-queries-per-second-on-neki): PlanetScale benchmarked Neki, its sharded Postgres, with single-shard primary-key point selects. Targeting about 200K QPS per shard, it went from 5 shards (about 1M QPS) to 50 (9.9M QPS, per-shard rate within 0.8%) to 512 shards and 480 routers, sustaining 118.5M QPS for 16 minutes over 1.22 PiB with a p99 of 6.06 ms at the router and about one error per 1.8 million queries. PlanetScale notes the run was read-only, primary-only with no replicas, and had no failover during the measured window.
- [Canva: Session revocations at scale](https://howtheyscaled.com/s/canva-session-revocations-at-scale): Canva keeps 12 hours of session revocations in memory on every gateway, but hundreds of pods each loading over a million revocations from MySQL on deploy caused a stampede on the database. A worker now packs revocations into sorted 16-byte records in 30-minute chunks on S3, using conditional PUTs for optimistic concurrency and ZooKeeper leader election to avoid conflicts, and reaches over 2,000 revocations per second. Gateways binary-search the downloaded bytes directly and poll with conditional GETs, which shrank the cache by 87.5% and cut the revocation database down to two read replicas kept for redundancy.
- [Zalando: Client-Side Load Balancing at a Million Requests Per Second](https://howtheyscaled.com/s/zalando-client-side-load-balancing-at-a-million-requests-per-second): Zalando moved the internal fan-out of its Product Read API off the shared Skipper ingress into an in-process JVM load balancer that rebuilds the same xxHash64 consistent-hash ring. They added N-ring fade-in so new pods warm only the products they will keep, bounded load based on occupancy (Little's Law) weighted by latency, and a capped ring walk. Pods ran more evenly, the autoscaler target rose from 50% to 65% CPU, and the fleet shrank by over 25%.
- [Datadog: When failover isn't safe: Building high-availability PostgreSQL on Kubernetes](https://howtheyscaled.com/s/datadog-when-failover-isn-t-safe-building-high-availability-postgresql-on-kubern): A gameday that injected network latency into one availability zone left several of Datadog's Kubernetes-based PostgreSQL clusters stuck: replicas lagged past Patroni's maximum_lag_on_failover, so no standby could be promoted safely. Datadog moved to a hybrid model: standbys in the leader pool take part in synchronous replication (one synchronous standby, synchronous_mode_strict, synchronous_commit=remote_apply) while read replicas stay asynchronous. pgbench showed remote_apply raised average latency by 53% and cut throughput by 34%, yet production clusters saw no measurable impact after a gradual rollout, and synchronous replication is now enabled in all of its clusters.
- [Shopify: We replaced Redis with MySQL for inventory reservations—and it scaled](https://howtheyscaled.com/s/shopify-we-replaced-redis-with-mysql-for-inventory-reservations-and-it-scaled): Shopify moved checkout inventory reservations from Redis to MySQL using one row per sellable unit, a bounded pool of 1,000 rows per item/location and SELECT ... FOR UPDATE SKIP LOCKED. The real ceiling was connections held by other checkout code: tagging SQL by business process and measuring hold time in ProxySQL found it, and the cleanup removed 50% of reads and 33% of transactions on the primary.
- [Discord: How Discord Automates ScyllaDB Clusters at Scale](https://howtheyscaled.com/s/discord-how-discord-automates-scylladb-clusters-at-scale): Discord's 7-person persistence team replaced fragile Python and bash scripts with the Scylla Control Plane, a Rust framework of idempotent tasks with declared preconditions, composed into YAML workflows. Jobs batch nodes by availability zone with concurrency limits to protect quorum, store their state in SQLite so they resume after interruptions, and send a webhook alert on unrecoverable errors. Operations like standing up shadow clusters and rolling upgrades went from a day and a half of babysitting to under two hours.
- [OpenAI: Scaling PostgreSQL to power 800 million ChatGPT users](https://howtheyscaled.com/s/openai-scaling-postgresql-to-power-800-million-chatgpt-users): OpenAI runs ChatGPT on a single-primary Postgres with nearly 50 global read replicas. Reads are offloaded, write-heavy shardable workloads move to Cosmos DB, and PgBouncer, cache leasing and multi-layer rate limits keep the primary safe.
- [Datadog: Scaling real-time file monitoring with eBPF: How we filtered billions of kernel events per minute](https://howtheyscaled.com/s/datadog-scaling-real-time-file-monitoring-with-ebpf-how-we-filtered-billions-of-): Datadog's eBPF-based file integrity monitoring sees more than 10 billion file events per minute, and at about 5 KB each, shipping them all would mean terabytes per second. Agent-side rules cut what goes upstream to roughly one million events per minute, and moving evaluation into the kernel stops the ring buffer from overflowing: static approvers compiled from detection rules let matching events through, while runtime discarders stored in LRU eBPF maps drop values no rule can match. Together they pre-filter up to 94% of events in the kernel with no dropped events.
- [Axiom: Haydex: From Zero to 178,600,000,000 rows a second in 30 days](https://howtheyscaled.com/s/axiom-haydex-from-zero-to-178-600-000-000-rows-a-second-in-30-days): Axiom turned a failed filter-index prototype into a production system for its event store, letting queries skip data and scan 178.6B rows per second.
- [Atlassian: Migrating the Jira Database Platform to AWS Aurora](https://howtheyscaled.com/s/atlassian-migrating-the-jira-database-platform-to-aws-aurora): Atlassian migrated about four million Jira databases from RDS Postgres to Aurora, balancing reliability, downtime and cost.
- [Datadog: Breaking up a monolith: How we're unwinding a shared database at scale](https://howtheyscaled.com/s/datadog-breaking-up-a-monolith-how-we-re-unwinding-a-shared-database-at-scale): Datadog is splitting its large shared Postgres database into team-owned instances in three phases. Logical separation moves tables into about 30 private domain schemas with explicit ACLs, using query samples and interviews with 30+ teams. Access reduction routes services through per-team PG Proxies so ACLs can be narrowed safely, and physical separation replicates each schema to a managed OrgStore instance, moves reads first and then writes with under five seconds of downtime, and replicates back for rollback. Two workloads have fully migrated and more than 70 dead tables were deleted along the way.
- [Notion: How we sped up Notion in the browser with WASM SQLite](https://howtheyscaled.com/s/notion-how-we-sped-up-notion-in-the-browser-with-wasm-sqlite): Notion cached data in the browser with WASM SQLite and OPFS, improving page navigation times.
- [Notion: Building and scaling Notion's data lake](https://howtheyscaled.com/s/notion-building-and-scaling-notion-s-data-lake): Notion replaced slow warehouse syncs with a CDC pipeline (Debezium to Kafka to Hudi on S3) processed with Spark.
- [Datadog: Timeseries indexing at scale](https://howtheyscaled.com/s/datadog-timeseries-indexing-at-scale): Datadog redesigned its timeseries indexing to handle a large jump in ingested data.
- [Meta: How Meta trains large language models at scale](https://howtheyscaled.com/s/meta-how-meta-trains-large-language-models-at-scale): Meta covers the hardware, networking and reliability work needed to train LLMs across very large GPU clusters.
- [GitHub: How we improved push processing on GitHub](https://howtheyscaled.com/s/github-how-we-improved-push-processing-on-github): GitHub broke one huge push-processing job into smaller, independently retried jobs driven by Kafka events.
- [Stripe: How Stripe's document databases supported 99.999% uptime with zero-downtime data migrations](https://howtheyscaled.com/s/stripe-how-stripe-s-document-databases-supported-99-999-uptime-with-zero-downtim): Stripe's DocDB and its Data Movement Platform move data between shards without downtime.
- [Figma: How Figma's Databases Team Lived to Tell the Scale](https://howtheyscaled.com/s/figma-how-figma-s-databases-team-lived-to-tell-the-scale): Figma's nine-month effort to horizontally shard its Postgres stack using a custom query proxy and logical sharding before physical splits.
- [Shopify: Horizontally scaling the Rails backend of Shop app with Vitess](https://howtheyscaled.com/s/shopify-horizontally-scaling-the-rails-backend-of-shop-app-with-vitess): Shopify's Shop app adopted Vitess to shard its Rails backend, covering keyspace design and the migration plan.
- [GitHub: Upgrading GitHub.com to MySQL 8.0](https://howtheyscaled.com/s/github-upgrading-github-com-to-mysql-8-0): How GitHub upgraded its whole MySQL fleet to 8.0 with staged replicas and a working rollback path.
- [Tiger Data (Timescale): How We Scaled PostgreSQL to 350 TB+](https://howtheyscaled.com/s/tiger-data-timescale-how-we-scaled-postgresql-to-350-tb): Timescale dogfooded its own Postgres extension to build a database-observability product, using hypertables, columnar compression and tiered storage to keep a 350 TB+ dataset queryable.
- [Supabase: Supavisor: Scaling Postgres to 1 Million Connections](https://howtheyscaled.com/s/supabase-supavisor-scaling-postgres-to-1-million-connections): Supabase load-tested Supavisor, its Elixir Postgres pooler, with a million client connections.
- [Notion: The Great Re-shard: adding Postgres capacity (again) with zero downtime](https://howtheyscaled.com/s/notion-the-great-re-shard-adding-postgres-capacity-again-with-zero-downtime): Notion tripled its Postgres fleet by re-sharding with logical replication and careful PgBouncer cutovers, with no downtime.
- [Slack: Real-time Messaging](https://howtheyscaled.com/s/slack-real-time-messaging): An overview of Slack's channel and gateway servers that fan messages out to millions of connected clients in real time.
- [Figma: The growing pains of database architecture](https://howtheyscaled.com/s/figma-the-growing-pains-of-database-architecture): How Figma moved from one Postgres instance to multiple databases by vertically partitioning table groups.
- [Discord: How Discord Stores Trillions of Messages](https://howtheyscaled.com/s/discord-how-discord-stores-trillions-of-messages): Discord moved its message store from Cassandra to ScyllaDB and put Rust data services in front of it to coalesce hot-partition requests.
- [Datadog: Husky: Exactly-once ingestion and multi-tenancy at scale](https://howtheyscaled.com/s/datadog-husky-exactly-once-ingestion-and-multi-tenancy-at-scale): A deep dive on how Husky routes, shards and ingests events exactly once across tenants.
- [Cloudflare: How we built Pingora, the proxy that connects Cloudflare to the Internet](https://howtheyscaled.com/s/cloudflare-how-we-built-pingora-the-proxy-that-connects-cloudflare-to-the-intern): Cloudflare replaced Nginx with Pingora, a Rust proxy that reuses connections better and needs less CPU and memory.
- [Cloudflare: Log analytics using ClickHouse](https://howtheyscaled.com/s/cloudflare-log-analytics-using-clickhouse): Cloudflare moved its error-log pipeline to ClickHouse and shares schema and query lessons.
- [PlanetScale: One million queries per second with MySQL](https://howtheyscaled.com/s/planetscale-one-million-queries-per-second-with-mysql): PlanetScale benchmarked a horizontally sharded Vitess cluster up to one million QPS.
- [GitLab: We are splitting our database into Main and CI](https://howtheyscaled.com/s/gitlab-we-are-splitting-our-database-into-main-and-ci): GitLab.com split CI tables into their own Postgres database to relieve its main database.
- [Datadog: Introducing Husky, Datadog's third-generation event store](https://howtheyscaled.com/s/datadog-introducing-husky-datadog-s-third-generation-event-store): Datadog's Husky is a distributed, schemaless column store that keeps event data on object storage.
- [Tailscale: Switching from etcd to SQLite: A Database Migration Story](https://howtheyscaled.com/s/tailscale-switching-from-etcd-to-sqlite-a-database-migration-story): Tailscale replaced etcd with SQLite plus Litestream replication for a simpler control-plane datastore.
- [Figma: LiveGraph: real-time data fetching at Figma](https://howtheyscaled.com/s/figma-livegraph-real-time-data-fetching-at-figma): Figma built LiveGraph, which tails the Postgres replication log so its UI can subscribe to live query results.
- [Notion: Herding elephants: Lessons learned from sharding Postgres at Notion](https://howtheyscaled.com/s/notion-herding-elephants-lessons-learned-from-sharding-postgres-at-notion): Notion split its Postgres monolith into a fleet of logical shards keyed by workspace, using double-writes and backfills to migrate.
- [GitLab: Why we spent the last month eliminating PostgreSQL subtransactions](https://howtheyscaled.com/s/gitlab-why-we-spent-the-last-month-eliminating-postgresql-subtransactions): GitLab traced replica stalls to Postgres subtransaction overflow and removed subtransactions from its code.
- [GitHub: Partitioning GitHub's relational databases to handle scale](https://howtheyscaled.com/s/github-partitioning-github-s-relational-databases-to-handle-scale): GitHub defined schema domains and linted cross-domain queries so it could move table groups onto separate MySQL clusters.
- [Shopify: Shard Balancing: Moving Shops Confidently with Zero-Downtime at Terabyte-scale](https://howtheyscaled.com/s/shopify-shard-balancing-moving-shops-confidently-with-zero-downtime-at-terabyte-): Shopify rebalances MySQL shards by moving individual shops online with its Ghostferry tool.
- [Meta: ZippyDB: Facebook's key value store](https://howtheyscaled.com/s/meta-zippydb-facebook-s-key-value-store): Meta's general-purpose distributed key-value store built on RocksDB, with shard management and configurable consistency.
- [Shopify: Read Consistency with Database Replicas](https://howtheyscaled.com/s/shopify-read-consistency-with-database-replicas): Shopify routes reads to MySQL replicas while giving apps consistency guarantees such as monotonic reads.
- [Shopify: Capacity Planning at Scale](https://howtheyscaled.com/s/shopify-capacity-planning-at-scale): How Shopify plans and checks capacity for traffic peaks like BFCM using forecasts and scalability tests.
- [Slack: Scaling Datastores at Slack with Vitess](https://howtheyscaled.com/s/slack-scaling-datastores-at-slack-with-vitess): Slack's multi-year migration from active-active MySQL pairs to Vitess, so data could be sharded by any key, not only workspace.
- [Cloudflare: Introducing Quicksilver: Configuration Distribution at Internet Scale](https://howtheyscaled.com/s/cloudflare-introducing-quicksilver-configuration-distribution-at-internet-scale): Quicksilver replicates Cloudflare's config key-value store to every edge server in seconds, built on LMDB.
- [Discord: Why Discord is switching from Go to Rust](https://howtheyscaled.com/s/discord-why-discord-is-switching-from-go-to-rust): Discord rewrote its Read States service from Go to Rust to get rid of garbage-collection latency spikes in a large in-memory cache.
- [Dropbox: How we optimized Magic Pocket for cold storage](https://howtheyscaled.com/s/dropbox-how-we-optimized-magic-pocket-for-cold-storage): Dropbox added a cold tier to Magic Pocket that cuts replication overhead for rarely read data.
- [Segment (Twilio): Goodbye Microservices](https://howtheyscaled.com/s/segment-twilio-goodbye-microservices): Segment folded more than 100 destination microservices back into a monolith to cut operational overhead.
- [Figma: How Mozilla's Rust dramatically improved our server-side performance](https://howtheyscaled.com/s/figma-how-mozilla-s-rust-dramatically-improved-our-server-side-performance): Figma rewrote its multiplayer server in Rust to cut latency and memory use as documents and users grew.
- [Cloudflare: HTTP Analytics for 6M requests per second using ClickHouse](https://howtheyscaled.com/s/cloudflare-http-analytics-for-6m-requests-per-second-using-clickhouse): Cloudflare rebuilt its HTTP analytics pipeline on ClickHouse, replacing a Postgres/Citus setup.
- [Discord: How Discord Scaled Elixir to 5,000,000 Concurrent Users](https://howtheyscaled.com/s/discord-how-discord-scaled-elixir-to-5-000-000-concurrent-users): Discord tuned its Elixir guild processes and fan-out paths, building custom libraries to push events to millions of concurrent users.
- [Slack: Flannel: An Application-Level Edge Cache to Make Slack Scale](https://howtheyscaled.com/s/slack-flannel-an-application-level-edge-cache-to-make-slack-scale): Slack added Flannel, an edge cache that serves user and channel data lazily so huge teams no longer need giant boot payloads.
- [Stripe: Scaling your API with rate limiters](https://howtheyscaled.com/s/stripe-scaling-your-api-with-rate-limiters): The four kinds of rate limiters and load shedders Stripe uses to protect its API.
- [Discord: How Discord Indexes Billions of Messages](https://howtheyscaled.com/s/discord-how-discord-indexes-billions-of-messages): Discord built message search on many small Elasticsearch clusters, sharding by guild and indexing lazily through a queue.
- [Stripe: Online migrations at scale](https://howtheyscaled.com/s/stripe-online-migrations-at-scale): Stripe's four-step dual-write playbook for migrating data models without downtime.
- [Discord: How Discord Stores Billions of Messages](https://howtheyscaled.com/s/discord-how-discord-stores-billions-of-messages): Early story of Discord outgrowing MongoDB and moving messages to Cassandra with a channel+time-bucket partition key.
- [LinkedIn: FollowFeed: LinkedIn's Feed Made Faster and Smarter](https://howtheyscaled.com/s/linkedin-followfeed-linkedin-s-feed-made-faster-and-smarter): LinkedIn moved its feed to a fan-out-on-read system that keeps member timelines in memory and on RocksDB.
- [Stack Overflow: Stack Overflow: The Architecture - 2016 Edition](https://howtheyscaled.com/s/stack-overflow-stack-overflow-the-architecture-2016-edition): A tour of how Stack Overflow serves a huge site from a small number of powerful servers with heavy caching.
- [LinkedIn: Running Kafka At Scale](https://howtheyscaled.com/s/linkedin-running-kafka-at-scale): How LinkedIn runs Kafka as its central data pipeline, including cluster tiers and mirroring between datacenters.
- [Meta: TAO: The power of the graph](https://howtheyscaled.com/s/meta-tao-the-power-of-the-graph): TAO is Facebook's geo-distributed graph cache over sharded MySQL, serving the social graph at more than a billion reads per second.
- [Dropbox: Scaling to exabytes and beyond](https://howtheyscaled.com/s/dropbox-scaling-to-exabytes-and-beyond): Dropbox built Magic Pocket, its own exabyte-class block store, and moved user data off third-party cloud storage.
- [Dropbox: How we migrated Dropbox from Nginx to Envoy](https://howtheyscaled.com/s/dropbox-how-we-migrated-dropbox-from-nginx-to-envoy): Dropbox moved its edge traffic proxy from Nginx to Envoy for better observability and extensibility.
- [Dropbox: Rewriting the heart of our sync engine](https://howtheyscaled.com/s/dropbox-rewriting-the-heart-of-our-sync-engine): Dropbox rewrote its desktop sync engine in Rust with a new data model built for correctness and testability.