Scale & Constraints

📖 7 min read 📄 Part 2 of 10

Distributed Counter - Scale and Constraints

Traffic Scale Analysis

Operation Volume

  • Peak Increments: 10 million increments per second globally
  • Average Increments: 3 million increments per second
  • Daily Increments: 250 billion increments per day
  • Read Operations: 1 million reads per second
  • Batch Operations: 10% of increments (batches of 100-1000)
  • Counter Updates: 100K counters updated per second

Counter Scale

  • Total Counters: 100 million active counters
  • Hot Counters: 1 million frequently accessed (top 1%)
  • Warm Counters: 10 million occasionally accessed (10%)
  • Cold Counters: 89 million rarely accessed (89%)
  • Counter Lifetime: Average 30 days, max 1 year
  • New Counters: 1 million created per day

Storage Requirements

In-Memory Storage (Redis/Memcached)

Hot Counters (1M):
- Counter ID: 8 bytes
- Count value: 8 bytes
- Metadata: 16 bytes (timestamp, version)
- Total per counter: 32 bytes
- Total: 1M × 32 bytes = 32 MB

Warm Counters (10M):
- Same structure: 32 bytes per counter
- Total: 10M × 32 bytes = 320 MB

Total Hot Storage: ~350 MB per server
With replication (3x): ~1 GB per server
Cluster (100 servers): ~100 GB total

Persistent Storage (Database)

All Counters (100M):
- Counter ID: 8 bytes
- Count value: 8 bytes
- Created timestamp: 8 bytes
- Updated timestamp: 8 bytes
- Metadata: 32 bytes
- Total per counter: 64 bytes
- Total: 100M × 64 bytes = 6.4 GB

Historical Data (Time-series):
- Per counter per hour: 24 bytes
- 100M counters × 24 hours × 30 days = 1.7 TB
- Compressed (10:1): 170 GB

Total Persistent Storage: ~180 GB

Backup and Archival

Daily Snapshots:
- Full snapshot: 6.4 GB
- Incremental: 1 GB per day
- 30-day retention: 36 GB

Long-term Archive:
- Monthly aggregates: 10 GB per month
- 1-year retention: 120 GB

Network Bandwidth

Inbound Traffic (Increments)

Increment Operations:
- 10M ops/s × 32 bytes = 320 MB/s
- Protocol overhead (20%): 64 MB/s
- Total inbound: ~384 MB/s peak

Batch Operations:
- 1M batches/s × 3.2 KB = 3.2 GB/s
- More efficient than individual ops

Outbound Traffic (Reads)

Read Operations:
- 1M reads/s × 32 bytes = 32 MB/s
- Protocol overhead (20%): 6.4 MB/s
- Total outbound: ~38 MB/s peak

Aggregation Queries:
- 10K queries/s × 1 KB = 10 MB/s
- Dashboard updates: 5 MB/s

Internal Traffic (Replication)

Cross-Server Sync:
- 10M ops/s × 32 bytes = 320 MB/s
- Replication factor 3: 640 MB/s
- Compression (2:1): 320 MB/s
- Total internal: ~320 MB/s

Compute Requirements

CPU Resources

Per Server:
- Increment processing: 10K ops/s × 0.01ms = 0.1 CPU core
- Hash computation: 10K ops/s × 0.02ms = 0.2 CPU cores
- Serialization: 10K ops/s × 0.01ms = 0.1 CPU core
- Network I/O: 0.5 CPU cores
- Replication: 0.5 CPU cores
- Total per server: ~1.5 CPU cores

Cluster (100 servers):
- Total: 150 CPU cores
- With overhead (2x): 300 CPU cores

Memory Resources

Per Server:
- Hot counters: 350 MB
- Connection buffers: 100 MB
- Application memory: 200 MB
- OS cache: 500 MB
- Total per server: ~1.2 GB

Cluster (100 servers):
- Total: 120 GB
- With overhead (1.5x): 180 GB

Latency Constraints

Operation Latency Breakdown

Local Increment (Same Server):
- Hash computation: 0.01ms
- Memory lookup: 0.05ms
- Atomic increment: 0.02ms
- Total: 0.08ms (P50), 0.2ms (P99)

Remote Increment (Different Server):
- Network RTT: 0.5ms
- Remote processing: 0.08ms
- Response: 0.5ms
- Total: 1.08ms (P50), 2ms (P99)

Read Operation:
- Hash computation: 0.01ms
- Memory lookup: 0.05ms
- Serialization: 0.02ms
- Total: 0.08ms (P50), 0.2ms (P99)

Aggregation Query:
- Fan-out to 10 servers: 1ms
- Parallel processing: 2ms
- Aggregation: 0.5ms
- Total: 3.5ms (P50), 10ms (P99)

Accuracy and Consistency

Accuracy Trade-offs

Strong Consistency (100% accurate):
- Synchronous updates across all replicas
- Latency: 5-10ms per operation
- Throughput: 100K ops/s per server
- Use case: Financial counters, votes

Eventual Consistency (99%+ accurate):
- Asynchronous updates
- Latency: <1ms per operation
- Throughput: 1M ops/s per server
- Convergence: <1 second
- Use case: Page views, analytics

Approximate Counting (95%+ accurate):
- Probabilistic data structures
- Latency: <0.5ms per operation
- Throughput: 10M ops/s per server
- Error rate: 1-5%
- Use case: Real-time dashboards

Convergence Time

Single Server: Immediate (0ms)
Same Region: <100ms
Cross-Region: <500ms
Global: <1 second

Factors Affecting Convergence:
- Network latency
- Replication lag
- Batch size
- Update frequency

Failure Scenarios

Server Failures

Single Server Failure:
- Impact: 1% of traffic (100 servers)
- Recovery: <30 seconds (load from replica)
- Data loss: 0 (replicated)

Multiple Server Failures:
- Impact: N% of traffic
- Recovery: <5 minutes
- Data loss: 0 (if <50% fail)

Network Partition:
- Impact: Temporary inconsistency
- Recovery: Automatic reconciliation
- Data loss: 0 (CRDTs handle merging)

Recovery Time Objectives

Server Restart: <30 seconds
- Load counters from disk
- Sync with cluster
- Resume operations

Cluster Recovery: <5 minutes
- Elect new coordinators
- Rebalance counters
- Restore full capacity

Disaster Recovery: <15 minutes
- Restore from backup
- Rebuild indexes
- Verify consistency

Cost Analysis

Infrastructure Costs (Monthly)

Compute:
- 100 servers × $100/month = $10,000
- Auto-scaling (avg 70%): $7,000

Memory/Cache:
- 180 GB Redis × $0.50/GB = $90

Storage:
- 200 GB SSD × $0.10/GB = $20
- 120 GB archive × $0.02/GB = $2.40

Network:
- 50 TB egress × $0.05/GB = $2,500

Total Infrastructure: ~$9,600/month

Operational Costs (Monthly)

Engineering: $5,000
Monitoring: $500
Support: $1,000
Total Operational: $6,500

Total Monthly Cost: $16,100

Cost Per Operation

Monthly Operations: 250B × 30 = 7.5 trillion
Cost per billion operations: $2.15
Cost per million operations: $0.00215
Cost per operation: $0.0000000021

Scaling Strategies

Horizontal Scaling

Add Servers:
- Linear scaling up to 1000 servers
- Rebalance counters automatically
- No downtime required

Shard by Counter ID:
- hash(counter_id) % num_servers
- Even distribution
- Consistent hashing for rebalancing

Vertical Scaling

Increase Server Size:
- Up to 32 cores, 128 GB RAM
- 10x capacity per server
- Reduce cluster size

Faster Storage:
- NVMe SSDs for persistence
- Larger Redis instances
- Better cache hit rates

Optimization Strategies

Batching:
- Batch 1000 increments
- Reduce network overhead by 100x
- Trade latency for throughput

Compression:
- Compress counter IDs (2:1 ratio)
- Compress time-series data (10:1 ratio)
- Reduce storage and bandwidth

Caching:
- Cache hot counters in memory
- 95% cache hit rate
- Reduce database load by 20x

Bottleneck Analysis

Primary Bottlenecks

1. Network Latency (Cross-region)
   - 100-300ms RTT
   - Mitigation: Regional deployment

2. Memory Capacity (Hot counters)
   - 1 GB per server limit
   - Mitigation: Larger instances, eviction

3. Synchronization Overhead
   - Coordination between servers
   - Mitigation: Eventual consistency

4. Database Write Throughput
   - 10K writes/s per shard
   - Mitigation: More shards, batching

5. Cache Invalidation
   - Stale reads possible
   - Mitigation: TTL-based expiration

This scale analysis provides the foundation for designing a counter system that handles massive operation volumes while maintaining accuracy and low latency.