smart_message 0.0.12 → 0.0.13

data/docs/transports/redis-transport-comparison.md

@@ -1,496 +1,361 @@
-# Redis Transport Comparison
+# Transport Comparison
 
-SmartMessage provides three distinct Redis-based transports, each designed for different use cases and requirements. This document provides a comprehensive comparison to help you choose the right transport for your application.
+SmartMessage provides multiple transport layers, each designed for different use cases and requirements. This document provides a comprehensive comparison to help you choose the right transport for your application.
 
 ## Transport Overview
 
 | Transport | Type | Best For | Key Feature |
 |-----------|------|----------|-------------|
-| **Redis** | Basic Pub/Sub | Simple scenarios, legacy compatibility | Lightweight, direct Redis pub/sub |
-| **Redis Enhanced** | Smart Routing | Microservices, pattern-based routing | RabbitMQ-style patterns with backwards compatibility |
-| **Redis Queue** | Persistent Queues | Production systems, load balancing | FIFO queues with consumer groups |
-
-![Transport Comparison Matrix](../assets/images/transport-comparison-matrix.svg)
+| **Memory** | In-Memory Queue | Testing, development | No external dependencies, fast |
+| **STDOUT** | Logging/Debug | Development, debugging | Human-readable output |
+| **Redis** | Pub/Sub | Production messaging | Distributed, persistent connections |
 
 ---
 
-## 🔧 Redis Transport (Basic)
+## 🧠 Memory Transport
 
-The foundational Redis transport using native pub/sub channels.
+Perfect for development, testing, and in-memory message queuing.
 
 ### Architecture
 ```
-Publisher → Redis Channel → Subscriber
-         (direct pub/sub)   (thread-based)
+Publisher → Memory Queue → Subscriber
+         (thread-safe)   (auto-processing)
 ```
 
-![Redis Basic Architecture](../assets/images/redis-basic-architecture.svg)
-
 ### Key Characteristics
-- **Channel Naming**: Uses message class name directly (`OrderMessage`)
-- **Pattern Support**: None - exact channel name matching only
-- **Message Persistence**: No - fire-and-forget pub/sub
+- **Message Persistence**: In-memory only - lost on restart
+- **Pattern Support**: None - direct message class routing
 - **Load Balancing**: No - all subscribers receive all messages
-- **Threading**: Traditional thread-per-subscriber model
-- **Backwards Compatibility**: Original SmartMessage Redis implementation
+- **Threading**: Thread-safe with mutex protection
+- **External Dependencies**: None
 
 ### Configuration
 ```ruby
-SmartMessage::Transport.create(:redis,
-  url: 'redis://localhost:6379',
-  db: 0,
-  auto_subscribe: true,
-  reconnect_attempts: 5,
-  reconnect_delay: 1
+SmartMessage::Transport.create(:memory,
+  auto_process: true,     # Automatically route messages to dispatcher
+  max_messages: 1000      # Maximum messages to store in memory
 )
 ```
 
 ### Use Cases
-- **Simple applications** with basic pub/sub needs
-- **Development/testing** environments
-- **Legacy systems** already using basic Redis transport
-- **Scenarios** where message loss is acceptable
-- **High-performance** applications needing minimal overhead
+- **Unit testing** - Predictable, isolated environment
+- **Development** - Quick setup without external services
+- **In-memory queuing** - Fast processing without persistence
+- **Message inspection** - Easy access to all stored messages
 
 ### Pros
-- ✅ Simplest implementation and configuration
-- ✅ Lowest resource overhead
-- ✅ Direct Redis pub/sub - maximum performance
-- ✅ No external dependencies beyond Redis
-- ✅ Battle-tested and stable
+- ✅ No external dependencies
+- ✅ Fastest performance (no serialization)
+- ✅ Thread-safe operations
+- ✅ Message inspection capabilities
+- ✅ Memory overflow protection
 
 ### Cons
-- ❌ No pattern-based routing
-- ❌ No message persistence
-- ❌ No load balancing capabilities
-- ❌ Limited routing intelligence
-- ❌ All-or-nothing message delivery
+- ❌ Messages lost on restart
+- ❌ Single-process only
+- ❌ Memory usage grows with message volume
+- ❌ No network distribution
 
 ### Example
 ```ruby
-class OrderMessage < SmartMessage::Base
-  transport SmartMessage::Transport.create(:redis, 
-    url: 'redis://localhost:6379'
-  )
+class TestMessage < SmartMessage::Base
+  property :data
   
-  property :order_id
-  property :amount
+  config do
+    transport SmartMessage::Transport.create(:memory, auto_process: true)
+  end
+  
+  def self.process(decoded_message)
+    puts "Processing: #{decoded_message.data}"
+  end
 end
 
-# Publishes to Redis channel "OrderMessage"
-OrderMessage.new(order_id: "123", amount: 99.99).publish
-
-# Subscribes to Redis channel "OrderMessage" 
-OrderMessage.subscribe
+TestMessage.subscribe
+TestMessage.new(data: "Hello World").publish
 ```
 
 ---
 
-## 🎯 Redis Enhanced Transport
+## 📄 STDOUT Transport
 
-Advanced Redis transport with intelligent routing and pattern matching.
+Ideal for development, debugging, and logging scenarios.
 
 ### Architecture
 ```
-Publisher → Enhanced Router → Dual Channels → Pattern Matcher → Subscriber
-         (3-part naming)   (orig + enhanced) (wildcard support) (thread-based)
+Publisher → Console/File Output → Optional Loopback → Subscriber
+         (JSON formatting)    (if enabled)      (local processing)
 ```
 
-![Redis Enhanced Architecture](../assets/images/redis-enhanced-architecture.svg)
-
 ### Key Characteristics
-- **Channel Naming**: Dual format - both `MessageClass` and `messagetype.from.to`
-- **Pattern Support**: Full wildcard support (`*` single segment, multiple patterns)
-- **Message Persistence**: No - still based on pub/sub
-- **Load Balancing**: No - all matching subscribers receive messages
-- **Threading**: Traditional thread-per-subscriber model
-- **Backwards Compatibility**: Yes - publishes to both channel formats
+- **Message Persistence**: File-based if output specified
+- **Pattern Support**: None - logging/debugging focused
+- **Load Balancing**: No - single output destination
+- **Threading**: Thread-safe file operations
+- **External Dependencies**: None
 
 ### Configuration
 ```ruby
-SmartMessage::Transport::RedisEnhancedTransport.new(
-  url: 'redis://localhost:6379',
-  db: 0,
-  auto_subscribe: true
+SmartMessage::Transport.create(:stdout,
+  loopback: true,                    # Process messages locally
+  output: "messages.log"             # Output to file instead of console
 )
 ```
 
-### Enhanced Features
-
-#### Pattern Subscriptions
-```ruby
-transport.subscribe_pattern("ordermessage.*.*")      # All order messages
-transport.subscribe_pattern("*.payment_service.*")   # All to payment service
-transport.subscribe_pattern("alertmessage.*.*")      # All alerts
-```
-
-#### Convenience Methods
-```ruby
-transport.subscribe_to_recipient('payment-service')  # *.*.payment-service
-transport.subscribe_from_sender('api-gateway')       # *.api-gateway.*
-transport.subscribe_to_type('OrderMessage')          # ordermessage.*.*
-transport.subscribe_to_alerts                        # emergency.*.*, *alert*.*.*
-transport.subscribe_to_broadcasts                    # *.*.broadcast
-```
-
-#### Fluent API
-```ruby
-transport.where.from('web-app').to('user-service').subscribe
-transport.where.type('OrderMessage').from('api').subscribe
-transport.where.from('monitoring').to('admin').type('AlertMessage').subscribe
-```
-
-![Fluent API Demo](../assets/images/fluent-api-demo.svg)
-
 ### Use Cases
-- **Microservices architectures** requiring sophisticated routing
-- **Migration scenarios** from basic Redis transport
-- **Development environments** needing flexible routing
-- **Pattern-based filtering** without message persistence requirements
-- **Service-to-service communication** with routing intelligence
+- **Development debugging** - See messages in real-time
+- **Application logging** - Structured message logging
+- **Message tracing** - Track message flow through system
+- **Integration testing** - Verify message content
 
 ### Pros
-- ✅ Advanced pattern-based routing
-- ✅ Fluent, readable subscription API
-- ✅ Backwards compatible with basic Redis transport
-- ✅ Sophisticated filtering capabilities
-- ✅ Service-oriented routing patterns
-- ✅ RabbitMQ-style routing without RabbitMQ
+- ✅ Human-readable JSON output
+- ✅ File-based persistence option
+- ✅ Optional loopback for testing
+- ✅ No external dependencies
+- ✅ Structured message formatting
 
 ### Cons
-- ❌ No message persistence
-- ❌ No load balancing
-- ❌ Pattern matching overhead (client-side)
-- ❌ Dual publishing increases Redis traffic
-- ❌ More complex configuration
+- ❌ Not suitable for production messaging
+- ❌ Single output destination
+- ❌ No network distribution
+- ❌ Limited throughput for high-volume scenarios
 
 ### Example
 ```ruby
-class OrderMessage < SmartMessage::Base
-  from 'e-commerce-api'
-  to 'order-processor'
-  
-  transport SmartMessage::Transport::RedisEnhancedTransport.new(
-    url: 'redis://localhost:6379'
-  )
+class LogMessage < SmartMessage::Base
+  property :level
+  property :message
+  property :timestamp, default: -> { Time.now.iso8601 }
   
-  property :order_id
-  property :amount
+  config do
+    transport SmartMessage::Transport.create(:stdout, 
+      output: "app.log",
+      loopback: false
+    )
+  end
 end
 
-# Publishes to BOTH:
-# - "OrderMessage" (backwards compatibility)  
-# - "ordermessage.e_commerce_api.order_processor" (enhanced)
-OrderMessage.new(order_id: "123", amount: 99.99).publish
-
-# Pattern-based subscriptions
-transport.where.from('e-commerce-api').subscribe
-transport.subscribe_to_type('OrderMessage')
+LogMessage.new(level: "INFO", message: "Application started").publish
 ```
 
 ---
 
-## 🚀 Redis Queue Transport
+## 🔴 Redis Transport
 
-Production-grade transport with persistent queues and load balancing.
+Production-ready Redis pub/sub transport for distributed messaging.
 
 ### Architecture
 ```
-Publisher → Routing Engine → Redis List → Consumer Group → Async Worker
-         (in-memory)     (LPUSH/BRPOP)  (load balancing) (fiber-based)
+Publisher → Redis Channel → Subscriber
+         (pub/sub)       (thread-based)
 ```
 
-![Redis Queue Architecture](../assets/images/redis-queue-architecture.svg)
-
 ### Key Characteristics
-- **Channel Naming**: Enhanced routing keys with queue-based delivery
-- **Pattern Support**: RabbitMQ-compatible wildcard patterns
-- **Message Persistence**: Yes - Redis Lists provide FIFO persistence
-- **Load Balancing**: Yes - consumer groups distribute messages
-- **Threading**: Async/fiber-based for massive concurrency
-- **Backwards Compatibility**: No - completely different architecture
+- **Message Persistence**: No - fire-and-forget pub/sub
+- **Pattern Support**: None - exact channel name matching
+- **Load Balancing**: No - all subscribers receive all messages
+- **Threading**: Traditional thread-per-subscriber model
+- **External Dependencies**: Redis server
 
 ### Configuration
 ```ruby
-SmartMessage.configure do |config|
-  config.transport = :redis_queue
-  config.transport_options = {
-    url: 'redis://localhost:6379',
-    db: 0,
-    queue_prefix: 'smart_message.queue',
-    exchange_name: 'smart_message',
-    consumer_group: 'workers',
-    consumer_id: SecureRandom.hex(4),
-    consumer_timeout: 1,
-    auto_subscribe: true
-  }
-end
-```
-
-### Advanced Features
-
-#### Load Balancing
-```ruby
-# Multiple consumers share work
-consumer_1 = RedisQueueTransport.new(consumer_group: 'workers', consumer_id: 'worker_1')
-consumer_2 = RedisQueueTransport.new(consumer_group: 'workers', consumer_id: 'worker_2')
-# Messages distributed between worker_1 and worker_2
-```
-
-#### Pattern-based Routing
-```ruby
-transport.subscribe_pattern("#.*.payment_service")     # RabbitMQ syntax
-transport.subscribe_pattern("order.#.*.*")             # Multi-segment wildcards
-transport.where().from('api').to('db').subscribe       # Fluent API
-```
-
-#### Queue Management
-```ruby
-transport.queue_stats                    # Queue lengths and info
-transport.routing_table                  # Active pattern mappings
-transport.where.from('api').build        # Preview pattern without subscribing
+SmartMessage::Transport.create(:redis,
+  url: 'redis://localhost:6379',    # Redis connection URL
+  db: 0,                            # Redis database number
+  auto_subscribe: true,             # Automatically start subscriber
+  reconnect_attempts: 5,            # Connection retry attempts
+  reconnect_delay: 1                # Delay between retries (seconds)
+)
 ```
 
-### Performance Characteristics
-
-| Metric | Value | Comparison |
-|--------|--------|------------|
-| **Latency** | ~0.5ms | 10x faster than RabbitMQ |
-| **Throughput** | 100K+ msg/sec | 3-5x faster than RabbitMQ |
-| **Concurrent Consumers** | 1000+ | 10x more than traditional threading |
-| **Memory per Consumer** | ~2KB | 1000x less than RabbitMQ connections |
-
 ### Use Cases
-- **Production systems** requiring message persistence
-- **Load-balanced processing** with multiple consumers
-- **High-throughput applications** needing maximum performance
-- **Fault-tolerant systems** where message loss is unacceptable
-- **Enterprise applications** requiring queue monitoring
+- **Production messaging** - Reliable distributed messaging
+- **Microservices communication** - Service-to-service messaging
+- **Real-time applications** - Low-latency message delivery
+- **Scalable architectures** - Multiple publishers and subscribers
 
 ### Pros
-- ✅ Message persistence and reliability
-- ✅ Load balancing and horizontal scaling
-- ✅ Exceptional performance (10x faster than RabbitMQ)
-- ✅ RabbitMQ-compatible routing patterns
-- ✅ Async/fiber concurrency for massive scale
-- ✅ Comprehensive queue management and monitoring
-- ✅ Consumer groups and fault tolerance
+- ✅ Production-ready reliability
+- ✅ Distributed messaging support
+- ✅ Automatic reconnection handling
+- ✅ Low latency (~1ms)
+- ✅ High throughput (80K+ messages/second)
+- ✅ Automatic serialization (MessagePack/JSON)
 
 ### Cons
-- ❌ More complex setup and configuration
-- ❌ No backwards compatibility with pub/sub transports
-- ❌ Requires understanding of async/fiber concepts
-- ❌ Additional memory overhead for queue management
-- ❌ Client-side pattern matching overhead
+- ❌ Requires Redis server
+- ❌ No message persistence
+- ❌ No pattern-based routing
+- ❌ No load balancing
+- ❌ All subscribers receive all messages
 
 ### Example
 ```ruby
 class OrderMessage < SmartMessage::Base
-  from 'e-commerce-api'
-  to 'order-processor'
-  
-  transport :redis_queue  # Uses global configuration
-  
   property :order_id
+  property :customer_id
   property :amount
   
-  def self.process(wrapper)
-    header, payload = wrapper.split
-    order_data = JSON.parse(payload)
-    # Process order with guaranteed delivery
+  config do
+    transport SmartMessage::Transport.create(:redis,
+      url: ENV['REDIS_URL'] || 'redis://localhost:6379',
+      db: 1
+    )
+  end
+  
+  def self.process(decoded_message)
+    order = decoded_message
+    puts "Processing order #{order.order_id} for $#{order.amount}"
   end
 end
 
-# Messages persist in Redis Lists until consumed
-OrderMessage.new(order_id: "123", amount: 99.99).publish
-
-# Load-balanced consumption across consumer group
 OrderMessage.subscribe
+OrderMessage.new(
+  order_id: "ORD-123",
+  customer_id: "CUST-456",
+  amount: 99.99
+).publish
 ```
 
 ---
 
 ## 📊 Feature Comparison Matrix
 
-| Feature | Basic Redis | Enhanced Redis | Redis Queue |
-|---------|------------|----------------|-------------|
-| **Message Persistence** | ❌ No | ❌ No | ✅ Yes |
-| **Pattern Matching** | ❌ No | ✅ Wildcards | ✅ RabbitMQ-style |
-| **Load Balancing** | ❌ No | ❌ No | ✅ Consumer Groups |
-| **Backwards Compatibility** | N/A | ✅ Dual Publishing | ❌ No |
-| **Fluent API** | ❌ No | ✅ Yes | ✅ Yes |
-| **Performance (Latency)** | ~1ms | ~1.2ms | ~0.5ms |
-| **Performance (Throughput)** | High | High | Highest |
-| **Concurrent Consumers** | ~100s | ~100s | ~1000s |
-| **Memory Overhead** | Low | Medium | Medium-High |
-| **Setup Complexity** | Low | Medium | High |
-| **Learning Curve** | Easy | Medium | Challenging |
-| **Production Ready** | ✅ Yes | ✅ Yes | ✅ Yes |
-| **Message Ordering** | No guarantees | No guarantees | ✅ FIFO |
-| **Dead Letter Queues** | ❌ No | ❌ No | ✅ Yes |
-| **Message TTL** | ❌ No | ❌ No | ✅ Yes |
-| **Consumer Acknowledgments** | ❌ No | ❌ No | ✅ Yes |
-| **Monitoring/Metrics** | Basic | Basic | ✅ Comprehensive |
+| Feature | Memory | STDOUT | Redis |
+|---------|--------|--------|-------|
+| **Message Persistence** | ❌ Memory Only | ✅ File Optional | ❌ No |
+| **Network Distribution** | ❌ No | ❌ No | ✅ Yes |
+| **External Dependencies** | ❌ None | ❌ None | ✅ Redis |
+| **Pattern Matching** | ❌ No | ❌ No | ❌ No |
+| **Load Balancing** | ❌ No | ❌ No | ❌ No |
+| **Setup Complexity** | Easy | Easy | Medium |
+| **Performance (Latency)** | ~0.1ms | ~1ms | ~1ms |
+| **Performance (Throughput)** | Highest | Medium | High |
+| **Serialization** | None | JSON | MessagePack/JSON |
+| **Thread Safety** | ✅ Yes | ✅ Yes | ✅ Yes |
+| **Message Inspection** | ✅ Yes | ✅ Yes | ❌ No |
+| **Production Ready** | ❌ Testing Only | ❌ Logging Only | ✅ Yes |
+| **Horizontal Scaling** | ❌ No | ❌ No | ✅ Yes |
 
 ---
 
 ## 🎯 Choosing the Right Transport
 
-### Use Basic Redis When:
-- ✅ You have simple pub/sub requirements
-- ✅ Message loss is acceptable
-- ✅ You need minimal setup and configuration
-- ✅ You're migrating from existing basic Redis pub/sub
-- ✅ Performance and simplicity are top priorities
-- ✅ You don't need sophisticated routing
-
-### Use Enhanced Redis When:
-- ✅ You need RabbitMQ-style routing without RabbitMQ
-- ✅ You have microservices requiring intelligent routing
-- ✅ You want backwards compatibility with basic Redis
-- ✅ You need pattern-based message filtering
-- ✅ Message persistence is not critical
-- ✅ You want a fluent, readable subscription API
-
-### Use Redis Queue When:
-- ✅ You need message persistence and reliability
-- ✅ You require load balancing across multiple consumers
-- ✅ You're building production systems with high throughput
-- ✅ You need enterprise features (DLQ, monitoring, etc.)
-- ✅ You can leverage async/fiber concurrency
-- ✅ You want RabbitMQ features with Redis performance
+### Use Memory Transport When:
+- ✅ You're writing unit tests
+- ✅ You're developing locally
+- ✅ You need fast, in-memory message processing
+- ✅ You want to inspect messages for testing
+- ✅ You don't need persistence or distribution
+
+### Use STDOUT Transport When:
+- ✅ You're debugging message flow
+- ✅ You need human-readable message logging
+- ✅ You're building development tools
+- ✅ You want to trace messages in integration tests
+- ✅ You need simple file-based message storage
+
+### Use Redis Transport When:
+- ✅ You're building production applications
+- ✅ You need distributed messaging
+- ✅ You have microservices that need to communicate
+- ✅ You need reliable, scalable messaging
+- ✅ You can manage a Redis server dependency
 
 ---
 
-## 🔄 Migration Paths
+## 🔄 Migration Patterns
 
-### From Basic → Enhanced
+### Development → Production
 ```ruby
-# Before (Basic)
-transport = SmartMessage::Transport.create(:redis, url: 'redis://localhost:6379')
-
-# After (Enhanced) - maintains backwards compatibility
-transport = SmartMessage::Transport::RedisEnhancedTransport.new(
-  url: 'redis://localhost:6379'
-)
-
-# Add pattern-based subscriptions gradually
-transport.where.from('api').subscribe
-```
-
-### From Enhanced → Queue
-```ruby
-# Before (Enhanced)
-class OrderMessage < SmartMessage::Base
-  transport SmartMessage::Transport::RedisEnhancedTransport.new(url: 'redis://localhost:6379')
-end
-
-# After (Queue) - requires architecture changes
-SmartMessage.configure do |config|
-  config.transport = :redis_queue
-  config.transport_options = { url: 'redis://localhost:6379' }
+# Development (Memory)
+class MyMessage < SmartMessage::Base
+  config do
+    transport SmartMessage::Transport.create(:memory, auto_process: true)
+  end
 end
 
-class OrderMessage < SmartMessage::Base
-  transport :redis_queue
-  
-  # Add proper async processing
-  def self.process(wrapper)
-    header, payload = wrapper.split
-    # Handle message processing
+# Production (Redis)
+class MyMessage < SmartMessage::Base
+  config do
+    transport SmartMessage::Transport.create(:redis,
+      url: ENV['REDIS_URL'] || 'redis://localhost:6379'
+    )
   end
 end
 ```
 
-### From Basic → Queue
+### Environment-Based Configuration
 ```ruby
-# Significant architectural changes required
-# Consider Enhanced as intermediate step for easier migration
+class MyMessage < SmartMessage::Base
+  config do
+    transport case Rails.env
+              when 'test'
+                SmartMessage::Transport.create(:memory, auto_process: true)
+              when 'development'
+                SmartMessage::Transport.create(:stdout, loopback: true)
+              when 'production'
+                SmartMessage::Transport.create(:redis, url: ENV['REDIS_URL'])
+              end
+  end
+end
 ```
 
 ---
 
-## 📈 Performance Testing
+## 📈 Performance Characteristics
 
-### Benchmark Setup
-```ruby
-# Test all three transports
-transports = {
-  basic: SmartMessage::Transport.create(:redis, url: 'redis://localhost:6379'),
-  enhanced: SmartMessage::Transport::RedisEnhancedTransport.new(url: 'redis://localhost:6379'),
-  queue: SmartMessage::Transport.create(:redis_queue, url: 'redis://localhost:6379')
-}
-
-# Measure latency, throughput, memory usage
-```
+### Latency Comparison
+- **Memory**: ~0.1ms (fastest, no serialization)
+- **STDOUT**: ~1ms (JSON formatting overhead)
+- **Redis**: ~1ms (network + serialization)
 
-### Expected Results
-- **Basic**: Lowest latency, highest throughput for simple scenarios
-- **Enhanced**: Slight overhead for pattern processing, excellent routing
-- **Queue**: Best overall performance with persistence and load balancing
+### Throughput Comparison
+- **Memory**: Highest (limited by CPU and memory)
+- **STDOUT**: Medium (limited by I/O operations)
+- **Redis**: High (limited by network and Redis performance)
 
-![Performance Comparison](../assets/images/performance-comparison.svg)
+### Memory Usage
+- **Memory**: Grows with message volume (configurable limit)
+- **STDOUT**: Minimal (immediate output/write)
+- **Redis**: Low (messages not stored locally)
 
 ---
 
 ## 🛠️ Configuration Examples
 
-### Development Environment
+### Test Environment
 ```ruby
-# Use Enhanced for flexible development routing
 SmartMessage.configure do |config|
-  config.default_transport = SmartMessage::Transport::RedisEnhancedTransport.new(
-    url: 'redis://localhost:6379',
-    db: 1  # Separate dev database
+  config.default_transport = SmartMessage::Transport.create(:memory,
+    auto_process: true,
+    max_messages: 100
   )
 end
 ```
 
-### Production Environment
+### Development Environment
 ```ruby
-# Use Queue for production reliability
 SmartMessage.configure do |config|
-  config.transport = :redis_queue
-  config.transport_options = {
-    url: ENV['REDIS_URL'],
-    db: 0,
-    queue_prefix: 'prod.smart_message',
-    consumer_group: ENV['CONSUMER_GROUP'] || 'default_workers',
-    consumer_timeout: 5,
-    reconnect_attempts: 10
-  }
+  config.default_transport = SmartMessage::Transport.create(:stdout,
+    loopback: true,
+    output: "log/messages.log"
+  )
 end
 ```
 
-### Hybrid Approach
+### Production Environment
 ```ruby
-# Different transports for different message types
-class LogMessage < SmartMessage::Base
-  transport SmartMessage::Transport.create(:redis, url: 'redis://localhost:6379')  # Fire-and-forget
-end
-
-class OrderMessage < SmartMessage::Base  
-  transport :redis_queue  # Persistent and reliable
-end
-
-class HealthCheckMessage < SmartMessage::Base
-  transport SmartMessage::Transport::RedisEnhancedTransport.new(
-    url: 'redis://localhost:6379'
-  )  # Pattern-based routing
+SmartMessage.configure do |config|
+  config.default_transport = SmartMessage::Transport.create(:redis,
+    url: ENV['REDIS_URL'],
+    db: ENV['REDIS_DB']&.to_i || 0,
+    reconnect_attempts: 10,
+    reconnect_delay: 2
+  )
 end
 ```
 
 ---
 
-## 📚 Additional Resources
-
-- [Basic Redis Transport Examples](https://github.com/madbomber/smart_message/tree/main/examples/redis_basic)
-- [Enhanced Redis Transport Examples](https://github.com/madbomber/smart_message/tree/main/examples/redis_enhanced)
-- [Queue Redis Transport Examples](https://github.com/madbomber/smart_message/tree/main/examples/redis_queue)
-- [Redis Queue Production Guide](../guides/redis-queue-production.md)
-- [Redis Queue Patterns Guide](../guides/redis-queue-patterns.md)
-- [Transport Reference](../reference/transports.md)
-
----
-
-This comparison should help you choose the right Redis transport for your specific use case. Each transport has its strengths and is optimized for different scenarios within the SmartMessage ecosystem.
+This comparison should help you choose the right transport for your specific use case within the SmartMessage ecosystem. Each transport is optimized for different scenarios and provides the flexibility to grow your application from development to production.