Struct SequentialWritePolicy 

pub struct SequentialWritePolicy;

Sequential write policy: Write to L1, then L2 (write-through).

This is the default and most common strategy. It provides:

• Strong consistency (both layers updated before returning)
• Atomic updates from caller’s perspective
• Graceful degradation if L1 succeeds but L2 fails

Behavior

1. Call write_l1(key)
   • If fails: Return error immediately (don’t write to L2)
   • If succeeds: Continue to L2
2. Call write_l2(key)
   • If fails: Return error (L1 has data, L2 doesn’t - inconsistent state)
   • If succeeds: Return success

Consistency Guarantees

Success case (Ok(())): Both L1 and L2 have been updated successfully.

Failure cases (Err):

• L1 write failed: Neither layer updated - cache remains consistent
• L2 write failed: L1 updated, L2 not updated - inconsistent state

Inconsistent State Handling

When L1 succeeds but L2 fails, the cache enters an inconsistent state where:

• L1 contains the new value - subsequent reads from this client will hit L1
• L2 may contain stale data or no data - other clients may see stale values
• The error is logged with tracing::error for monitoring

Mitigation Strategies:

1. Accept inconsistency - If L1 is much faster and L2 failures are rare, the inconsistency may be acceptable as L1 will mask it for most reads

2. Retry logic - Implement retry at application level or use a RetryBackend wrapper to retry failed L2 writes

3. Use OptimisticParallelWritePolicy - Succeeds if either L1 or L2 succeeds, providing better availability at the cost of potential inconsistency

4. Monitor and alert - Track L2 write failures via metrics and investigate persistent failures that could indicate L2 capacity or connectivity issues

When L2 Failures Are Acceptable:

• L2 is a persistent cache for cold starts (L1 mask inconsistency during normal operation)
• Cache data is regeneratable from source of truth
• Read-heavy workload where L1 hit rate is very high

Implementations

impl SequentialWritePolicy

pub fn new() -> Self

Create a new sequential write policy.

Trait Implementations

impl Clone for SequentialWritePolicy

fn clone(&self) -> SequentialWritePolicy

Returns a duplicate of the value.

fn clone_from(&mut self, source: &Self)

Performs copy-assignment from source.

impl CompositionWritePolicy for SequentialWritePolicy

fn execute_with<'life0, 'life1, 'async_trait, F1, F2, Fut1, Fut2, O>( &'life0 self, key: CacheKey, write_l1: F1, write_l2: F2, _offload: &'life1 O, ) -> Pin<Box<dyn Future<Output = Result<(), BackendError>> + Send + 'async_trait>>

where F1: FnOnce(CacheKey) -> Fut1 + Send + 'async_trait, F2: FnOnce(CacheKey) -> Fut2 + Send + 'async_trait, Fut1: Future<Output = Result<(), BackendError>> + Send + 'static + 'async_trait, Fut2: Future<Output = Result<(), BackendError>> + Send + 'static + 'async_trait, O: Offload<'static> + 'async_trait, Self: 'async_trait, 'life0: 'async_trait, 'life1: 'async_trait,

Execute a write operation with custom write closures for each layer.

impl Debug for SequentialWritePolicy

fn fmt(&self, f: &mut Formatter<'_>) -> Result

Formats the value using the given formatter.

impl Default for SequentialWritePolicy

fn default() -> SequentialWritePolicy

Returns the “default value” for a type.

impl Copy for SequentialWritePolicy