Shopify

Capacity Planning at Scale

How Shopify plans and checks capacity for traffic peaks like BFCM using forecasts and scalability tests.

Published
2020-12-03
Scale
Not stated in source
Techniques
capacity planning load testing
Stack
Kubernetes GCP

Try this stack yourself

  • Better Stack · Monitor uptime and logs with Better Stack, and get alerted fast if a migration or traffic spike goes sideways on your own system.
    Better Stack isn't part of Shopify's setup in this story. It's a tool for watching your own systems while you try ideas like these.

Some links above are affiliate links: if you sign up, How They Scaled may earn a commission at no extra cost to you. We only list tools that fit the stack in the story.

See also

Shopify architecture

The best scaling write-ups, weekly

One email a week. No spam.

Subscribe

Related stories

Meta · 2026

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.

30 million+ WhatsApp messages/sec8.4 billion messages in 5 minutescapacity planningload testingload sheddingTaijiKatranProxygen
Zalando · 2026

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%.

1 million+ requests/sec moved off shared ingressup to 100 downstream calls per batchload balancingconsistent hashingcachingJavaKubernetesSkipper
Datadog · 2026

When failover isn't safe: Building high-availability PostgreSQL on Kubernetes

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.

+53% avg write latency with remote_apply (pgbench TPC-B)-34% tps with remote_apply (pgbench TPC-B)synchronous replicationfailoverhigh availabilityPostgreSQLKubernetesPatroni
OpenAI · 2026

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.

800 million usersmillions of QPSread replicasconnection poolingcachingPostgreSQLAzurePgBouncer