Performance Optimization Proposal for High-Frequency Updates - Include Simple Values in Backplane Messages

[svetoslav-sportinno]

Hi there,

We're huge fans of FusionCache's architecture and how it handles the complexity of distributed caching!

I'm reaching out regarding a potential optimization for FusionCache that could significantly improve performance in high-frequency update scenarios.

Our Use Case: Sports Betting Platform

We're building a real-time sports betting platform where we need to update event data extremely frequently:

• Event Updates: Each sports event has a "version" field (long) that increments with every odds change
• Scale: 1000+ live sports events simultaneously during peak times
• Total Load: This results in 1,000+ cache updates per second across our distributed system
• Architecture: Multiple cache nodes (consumers) need to stay synchronized with these rapid updates

Currently, every update triggers:

1. Producer updates L2 (Redis)
2. Backplane notification sent to all consumer nodes
3. Each consumer fetches the updated value from Redis
4. Consumer updates its L1 memory cache

With 10 consumer nodes and 1k updates/second, this creates 10,000 Redis read operations per second just for cache synchronization.

Proposed Optimization: Include Simple Values in Backplane Messages

For simple value types like long, int, etc., we propose including the actual value directly in the backplane notification message instead of just the key and timestamp.

Current Flow:

Producer: Update Redis → Send Backplane(key, timestamp, SET)
Consumer: Receive notification → Fetch from Redis → Update L1

Optimized Flow:

Producer: Update Redis → Send Backplane(key, timestamp, SET, value)
Consumer: Receive notification → Update L1 directly (no Redis fetch)

Performance Impact:

• Redis Read Load Reduction
• Update Latency: 10-100x improvement (microseconds vs milliseconds)
• Infrastructure Costs: Dramatic reduction in Redis IOPS requirements
• Scalability: System can handle much higher update frequencies

Size Considerations:

• long value: +8 bytes per backplane message
• Eliminated Redis read: -64+ bytes per operation (protocol overhead)
• Net bandwidth reduction despite slightly larger backplane messages

Implementation Suggestions:

1. Size threshold: Only include values ≤ 64-128 bits
2. Type filtering: Limit to simple value types initially (long, int, double, bool, etc.)
3. Graceful fallback: If value not included, fall back to current Redis-fetch behavior
4. Backward compatibility: Optional feature that doesn't break existing implementations
5. Maybe Expand FusionCacheEntryOptions

Proposed BackplaneMessage Enhancement:

public class BackplaneMessage {
public string SourceId;
public string CacheKey;
public BackplaneMessageAction Action;
public long Timestamp;
public byte[]? SerializedValue; // NEW: Optional serialized value or maybe T?
public bool HasValue; // NEW: Flag indicating value is included
}

This optimization would be particularly valuable for scenarios like ours where:

• High update frequency (hundreds/thousands per second)
• Simple value types (version numbers, counters, timestamps)
• Multiple distributed cache consumers
• Redis/L2 cache becoming a bottleneck

Would you be interested in discussing this enhancement? We'd be happy to contribute to the implementation or provide more detailed performance testing if this aligns with FusionCache's roadmap.

Best regards,
Svetoslav Mitov.