Optimal Cluster Sizes:
- 3 nodes: Development, small scale
- 5 nodes: Production (recommended)
- 7 nodes: High availability

Why Not More?
- Consensus overhead increases with cluster size
- Write latency grows (more nodes to replicate)
- Network bandwidth increases
- Diminishing returns beyond 7 nodes

Quorum Requirements:
- 3 nodes: 2 for quorum (tolerates 1 failure)
- 5 nodes: 3 for quorum (tolerates 2 failures)
- 7 nodes: 4 for quorum (tolerates 3 failures)

Strategies:
1. Follower Reads (Stale):
   - Read from any node
   - May return stale data
   - High throughput

2. Linearizable Reads:
   - Read from leader only
   - Always consistent
   - Limited by leader capacity

3. Lease-Based Reads:
   - Followers with read leases
   - Bounded staleness
   - Good balance

Batch Lock Acquisitions:
- Group multiple lock requests
- Single Raft log entry
- Reduces consensus overhead
- 10x throughput improvement

Implementation:
- Client-side batching
- Server-side coalescing
- Configurable batch window (10ms)

Client Connection Management:
- Pool size: 10-50 connections
- Connection reuse
- Health checking
- Automatic failover

Challenges:
- High latency between DCs
- Network partitions
- Consistency vs availability

Solutions:
1. Single Cluster Across DCs:
   - Strong consistency
   - High write latency
   - Suitable for <100ms RTT

2. Multiple Independent Clusters:
   - Low latency per region
   - No cross-region consistency
   - Application-level coordination