Skip to main content
The CAP theorem states that distributed systems can only guarantee two of three properties: Consistency, Availability, and Partition Tolerance. GUN makes specific tradeoffs to optimize for real-world, decentralized applications.

GUN’s CAP Tradeoffs

GUN chooses Availability and Partition Tolerance over strong consistency:
  • ✅ Availability: Always accepts reads and writes
  • ✅ Partition Tolerance: Continues operating during network splits
  • ⚠️ Consistency: Eventual consistency (not strong consistency)
This makes GUN an AP system in CAP theorem terminology.

Why AP Over CP?

Real-World Networks Are Unreliable

Network partitions are not rare edge cases - they’re common in:
  • Mobile applications (airplane mode, poor signal)
  • Geographic distribution (cross-continent latency)
  • Peer-to-peer networks (dynamic topology)
  • IoT devices (intermittent connectivity)
Source: GUN is designed for offline-first, decentralized applications

Offline-First Architecture

GUN applications work offline by default:

Eventual Consistency Model

All peers eventually converge to the same state:
Source: GUN uses state-based CRDTs for conflict resolution

Understanding Eventual Consistency

What Is Eventual Consistency?

Eventual consistency guarantees that:
  1. All replicas will eventually have the same data
  2. If no new updates are made, all reads will eventually return the same value
  3. There’s no guarantee about when consistency will be achieved

Consistency Guarantees

GUN provides these guarantees:
  • Monotonic reads: You’ll never see older data after seeing newer data from the same source
  • Read your writes: You’ll always see your own writes
  • Causal consistency: If operation B depends on operation A, all peers see them in order

Consistency Timeline

Handling Network Partitions

Split Brain Scenario

When the network partitions, each side continues operating:
Source: Conflict resolution uses state timestamps

Partition Detection

GUN doesn’t explicitly detect partitions - it assumes partitions are always possible:
Source: ~/workspace/source/src/mesh.js:266-294

Healing After Partition

Source: ~/workspace/source/src/mesh.js:337-345

Consistency Levels

Local Consistency (Immediate)

Peer Consistency (Milliseconds to Seconds)

Global Consistency (Seconds to Minutes)

In large mesh networks:
  • Updates propagate peer-to-peer
  • Convergence time depends on network topology
  • Updates may take multiple hops to reach all peers

Strong Consistency vs Eventual Consistency

Strong Consistency (NOT GUN)

Eventual Consistency (GUN)

When Consistency Matters

Use Cases That Need Strong Consistency

❌ Not ideal for GUN:
  • Financial transactions (double-spend prevention)
  • Inventory management (overselling prevention)
  • Monotonic counters (must always increment)
  • Unique constraints (username uniqueness)

Use Cases That Work With Eventual Consistency

✅ Perfect for GUN:
  • Social media posts and comments
  • Collaborative documents
  • Chat messages
  • User profiles
  • Gaming leaderboards (approximate)
  • Analytics and metrics (approximate)
  • Content management systems
  • Real-time dashboards

Working Around Consistency Limitations

Optimistic UI Updates

Idempotent Operations

Design operations that can be safely retried:

Application-Level Consensus

Implement consensus in your application:

Conflict-Free Data Structures

Use CRDTs that guarantee convergence:

Availability Guarantees

Always Accept Writes

GUN never blocks writes:

Always Accept Reads

Reads return the latest known data:

Graceful Degradation

Partition Tolerance

Mesh Network Resilience

GUN’s mesh architecture provides multiple paths:
Source: ~/workspace/source/src/mesh.js implements mesh routing

Relay Peers

Relay peers improve partition tolerance:

AXE Protocol

AXE (Advanced eXchange Engine) optimizes routing during partitions:
Source: ~/workspace/source/lib/axe.js:13 AXE features:
  • Smart routing: Finds alternative paths during partitions
  • Subscription tracking: Routes updates to interested peers only
  • Load balancing: Distributes queries across available peers

Monitoring Consistency

Track Convergence Time

Detect Conflicts

Measure Peer Lag

Best Practices

  1. Embrace eventual consistency: Design for it, don’t fight it
  2. Use optimistic UI updates: Show changes immediately
  3. Handle conflicts gracefully: Update UI when conflicts resolve
  4. Design idempotent operations: Safe to retry
  5. Use CRDTs: Conflict-free data structures
  6. Monitor convergence: Track how long sync takes
  7. Provide feedback: Show online/offline status
  8. Test partition scenarios: Simulate network failures
  9. Implement retries: For critical operations
  10. Use multiple relay peers: Improve partition tolerance

Comparison with Other Systems

PostgreSQL (CP)

  • Strong consistency
  • Blocks during partitions
  • Requires distributed consensus
  • Not offline-first

Cassandra (AP)

  • Eventual consistency (tunable)
  • Available during partitions
  • Partition-tolerant
  • Requires servers

GUN (AP)

  • Eventual consistency
  • Always available
  • Partition-tolerant
  • Truly decentralized (works in browsers)
  • Offline-first

Trade-off Summary

When to Use GUN

✅ Use GUN when:
  • Building offline-first applications
  • Need real-time collaboration
  • Want decentralized architecture
  • Eventual consistency is acceptable
  • Building P2P applications
❌ Don’t use GUN when:
  • Need strong consistency (financial transactions)
  • Require ACID guarantees
  • Need complex queries (joins, aggregations)
  • Building traditional CRUD apps

Next Steps