Shard the Orders Database

Orders runs on one Postgres primary with 6 TB of data and two read replicas. Write volume doubles every 14 months, and the primary reached 85% CPU at last year's holiday peak.

We didn't evaluate alternatives, since sharding is the standard approach at this size.

Orders are sharded by creation month across 12 shards in rotation: January's orders go to shard 1, February's to shard 2, and so on.

Each shard keeps its own Postgres sequence for order IDs, as the single database does today.

Order history pages query all 12 shards in parallel and merge the results.

Checkout writes the order, its line items, and the inventory reservation in one transaction, as it does now. Inventory stays on the current database.

Twelve shards cover projected growth for five years, so the design doesn't include a way to add shards.

The 6 TB copy runs during a four hour maintenance window on a Sunday night, with checkout disabled.

Each shard gets the same dashboards and alerts as today's primary.