STANDARDwalkthrough
Sharding with Logical Partitions
When a PostgreSQL server fills its disk or maxes its CPU, we need to move data. But resharding millions of rows with a modulo-based scheme means remapping every row when the shard count changes.
We pre-define 8,192 logical shards mapped to roughly 30 physical PostgreSQL servers. Assignment: user_id mod 8192.
“We chose logical sharding (not hash-mod-N directly to physical servers) because it decouples the routing function from hardware.”
Each physical server hosts multiple logical shards, with each shard in its own PostgreSQL schema. When a server gets hot, we migrate entire logical shards to new hardware.
No rehashing, no row splitting, no application changes. Why 8,192?
Because gives enough granularity that each shard holds a small enough data slice to migrate in minutes, while fitting in 13 bits of our 64-bit ID. The PL/pgSQL ID generator embeds the logical shard ID directly into every photo ID, so any service extracts the shard by bit-shifting.
This eliminates a separate shard-lookup service. Trade-off: we decouple logical from physical partitioning at the cost of an extra mapping layer (logical shard to physical host).
If a logical shard itself becomes too large, we cannot split it without changing the mod function. What if the interviewer asks: what happens when you outgrow 8,192 shards?
At current growth, 8,192 shards last roughly 10 years. Beyond that, a shard-split migration (doubling to 16,384) would require rewriting IDs, a painful but infrequent operation.
Related concepts