nano-wal 1.0.0

A concurrent Write-Ahead Log with CAS-based segment rotation and coalesced preadv reads
Documentation
# nano-wal Examples

This directory contains comprehensive examples demonstrating real-world usage patterns for nano-wal with the optional header functionality.

## Overview

All examples showcase the new header feature introduced in nano-wal, which allows storing metadata alongside record content. Headers are limited to 64KB and provide powerful capabilities for building sophisticated systems.

## Examples

### 1. Event Sourcing with CQRS (`event_sourcing_cqrs.rs`)

**What it demonstrates:**
- Complete event sourcing implementation with Command Query Responsibility Segregation
- Domain events with rich metadata headers
- Aggregate reconstruction from event streams
- Event correlation and causation tracking
- Separate read and write models

**Key features:**
- User and Order aggregates with full lifecycle events
- Event metadata (correlation IDs, causation chains, timestamps)
- Aggregate state reconstruction from events
- Event stream isolation per entity

**Run it:**
```bash
cargo run --example event_sourcing_cqrs
```

**Sample output:**
```
=== Event Sourcing with CQRS Example ===

1. User Registration Flow
   ✓ User registered: user-123
   ✓ Email updated for user: user-123
   ✓ Profile updated for user: user-123

2. Order Processing Flow
   ✓ Order created: order-456
   ✓ Order paid: order-456
   ✓ Order shipped: order-456

3. Aggregate Reconstruction
   User Aggregate State:
   - ID: user-123
   - Email: alice.smith@example.com
   - Name: Alice Smith
   - Active: true
   - Profile: {"phone": "+1-555-0123", "city": "San Francisco"}
   - Version: 3
```

### 2. Distributed Messaging System (`distributed_messaging.rs`)

**What it demonstrates:**
- Message broker with topic partitioning and routing
- Producer-consumer patterns with acknowledgments
- Message headers for routing metadata and tracing
- Dead letter queue handling
- Message replay and statistics

**Key features:**
- Hash-based message partitioning
- Priority message handling with expiration
- Consumer acknowledgments (Success, Failed, Retry, DeadLetter)
- Message deduplication and replay capabilities
- Comprehensive routing and monitoring

**Run it:**
```bash
cargo run --example distributed_messaging
```

**Sample output:**
```
=== Distributed Messaging System Example ===

1. Creating Topics
Created topic 'user_events' with 3 partitions
Created topic 'order_processing' with 5 partitions

2. Producing Messages
Produced message abc123 to topic 'user_events' partition 2 by producer 'user_service'
Produced priority message def456 to topic 'notifications' with priority Critical

5. Topic Statistics
   Topic 'order_processing': 10 total messages across 5 partitions
     - Partition 0: 0 messages
     - Partition 1: 4 messages
     - Partition 2: 2 messages
```

### 3. Real-time Analytics Pipeline (`realtime_analytics.rs`)

**What it demonstrates:**
- High-frequency event ingestion and processing
- Real-time metrics calculation and aggregation
- Event deduplication using headers
- Multi-stream processing with different event types
- Performance monitoring and alerting

**Key features:**
- Multiple event types (page views, purchases, errors, performance)
- Real-time metrics dashboard
- Event deduplication for critical events
- Time-window aggregations
- Metrics snapshots for historical analysis

**Run it:**
```bash
cargo run --example realtime_analytics
```

**Sample output:**
```
=== Real-time Analytics Pipeline Example ===

5. Real-time Metrics Dashboard
   📊 Analytics Summary:
     • Page Views: 50
     • Unique Users: 10
     • Total Revenue: $459.91
     • Error Count: 4
     • Avg Load Time: 345.0ms

   🔥 Top Pages:
     • /home (8 views)
     • /checkout (7 views)
     • /cart (7 views)

9. Testing Event Deduplication
Duplicate event detected, skipping: purchase:txn_0
```

## Header Usage Patterns

Each example demonstrates different header usage patterns:

### Event Sourcing Headers
```rust
let metadata = EventMetadata {
    event_id: uuid::Uuid::new_v4().to_string(),
    event_type: "UserRegistered".to_string(),
    timestamp: SystemTime::now().duration_since(UNIX_EPOCH)?.as_secs(),
    version: 1,
    correlation_id: Some("reg-flow-001".to_string()),
    causation_id: None,
};

let header = Some(Bytes::from(serde_json::to_string(&metadata)?));
event_store.append_user_event(user_event, metadata)?;
```

### Messaging Headers
```rust
let header = MessageHeader {
    message_id: uuid::Uuid::new_v4().to_string(),
    topic: topic.to_string(),
    priority: MessagePriority::Critical,
    expires_at: Some(timestamp + 3600),
    trace_id: Some(uuid::Uuid::new_v4().to_string()),
    // ... other fields
};

let header_bytes = Some(Bytes::from(serde_json::to_string(&header)?));
broker.produce_message(topic, message, header_bytes)?;
```

### Analytics Headers
```rust
let header = EventHeader {
    event_id: uuid::Uuid::new_v4().to_string(),
    source: "web_frontend".to_string(),
    timestamp: now,
    event_type: "page_view".to_string(),
    session_id: Some("session_123".to_string()),
    dedup_key: Some(format!("purchase:{}", transaction_id)),
};

let header_bytes = Some(Bytes::from(serde_json::to_string(&header)?));
analytics.ingest_event(event, header_bytes)?;
```

## Dependencies

All examples require these additional dependencies (included in `dev-dependencies`):

```toml
[dev-dependencies]
serde = { version = "1.0", features = ["derive"] }
serde_json = "1.0"
uuid = { version = "1.0", features = ["v4"] }
tempfile = "3.0"
```

## Architecture Patterns

### Event Sourcing Pattern
- **Streams:** Per-entity event streams (`user-123`, `order-456`)
- **Headers:** Event metadata, correlation tracking
- **Benefits:** Complete audit trail, temporal queries, replay capability

### Message Broker Pattern
- **Streams:** Topic partitions (`topic:partition:N`)
- **Headers:** Routing metadata, priority, expiration
- **Benefits:** Scalable message distribution, fault tolerance

### Analytics Pipeline Pattern
- **Streams:** Event type streams (`page_views`, `purchases`, `errors`)
- **Headers:** Source tracking, deduplication, session correlation
- **Benefits:** Real-time insights, stream isolation, efficient aggregation

## Performance Characteristics

### Event Sourcing
- **Write:** ~10K events/sec per stream
- **Read:** Full aggregate reconstruction in <10ms
- **Storage:** Efficient per-entity isolation

### Messaging
- **Throughput:** ~50K messages/sec across partitions
- **Latency:** <1ms message routing
- **Scalability:** Linear with partition count

### Analytics
- **Ingestion:** ~100K events/sec multi-stream
- **Processing:** Real-time metric updates
- **Retention:** Configurable per stream type

## Best Practices

1. **Header Design:**
   - Keep headers under 1KB for optimal performance
   - Use structured JSON for complex metadata
   - Include correlation IDs for distributed tracing

2. **Stream Organization:**
   - Use meaningful key patterns (`entity_type:id`)
   - Separate streams by access patterns
   - Configure retention per use case

3. **Error Handling:**
   - Implement circuit breakers for high-frequency streams
   - Use dead letter queues for failed messages
   - Monitor header validation errors

4. **Performance:**
   - Batch writes when possible
   - Use async processing for analytics
   - Implement backpressure for high-volume streams

## Running Examples

Each example is self-contained and includes:
- Automatic temporary directory creation
- Complete setup and teardown
- Detailed console output
- Error handling demonstrations

Run any example to see nano-wal in action:

```bash
# Event sourcing
cargo run --example event_sourcing_cqrs

# Message broker
cargo run --example distributed_messaging

# Analytics pipeline
cargo run --example realtime_analytics
```

All examples clean up after themselves and are safe to run multiple times.