Migrating to Horizontal Sharding

1. The Bottleneck

Our primary PostgreSQL instance reached 85% CPU utilization during peak windows. Vertical scaling (upgrading to db.m6g.16xlarge) provided a temporary buffer, but write latency continued to degrade linearly with user growth.

Symptoms

• P99 Write Latency: > 450ms
• Connection Pool Saturation
• Frequent Deadlocks

2. Migration Checklist

To ensure a zero-downtime transition, we followed this strict execution plan:

• Baseline performance benchmarking
• Schema compatibility audit (removing foreign keys across shards)
• Implementation of consistent hashing algorithm
• [i] Shadow writing to new shards (In Progress)
• Final cutover and decommissioning of legacy master

3. The Sharding Strategy

We opted for application-level sharding based on tenant_id. This decision was driven by the isolation requirements of our B2B customers.

typescript
// Simplified Sharding Logic
function getShard(tenantId: string): string {
  const hash = fnv1a(tenantId);
  const shardIndex = hash % TOTAL_SHARDS;
  return `shard_${shardIndex}`;
}

4. Implementation Challenges

The migration wasn't without issues. The biggest hurdle was handling cross-shard transactions.

"Distributed transactions are the silent killer of availability."

We refactored our billing service to be eventually consistent, using an outbox pattern to ensure reliability without locking multiple shards simultaneously.

5. Visualizing the New Topology

Below is a conceptual schematic of the sharded architecture:

6. Performance Delta

The system is now stable at 10x the original load with room for linear horizontal expansion.