Enum CheckpointingMode 

pub enum CheckpointingMode {
    Eager,
    Batched,
    Optimistic,
}

Checkpointing mode that controls the trade-off between durability and performance.

The checkpointing mode determines when and how often the SDK persists operation state to the durable execution service. Different modes offer different trade-offs:

Modes

Eager Mode

• Checkpoints after every operation completes
• Maximum durability: minimal work is lost on failure
• More API calls: higher latency and cost
• Best for: Critical workflows where every operation must be durable

Batched Mode (Default)

• Groups multiple operations into batches before checkpointing
• Balanced durability: some operations may be replayed on failure
• Fewer API calls: better performance and lower cost
• Best for: Most workflows with reasonable durability requirements

Optimistic Mode

• Executes multiple operations before checkpointing
• Minimal durability: more work may be replayed on failure
• Best performance: fewest API calls
• Best for: Workflows where replay is cheap and performance is critical

Example

use durable_execution_sdk::CheckpointingMode;

// Use eager mode for maximum durability
let eager = CheckpointingMode::Eager;

// Use batched mode for balanced performance (default)
let batched = CheckpointingMode::default();

// Use optimistic mode for best performance
let optimistic = CheckpointingMode::Optimistic;

Requirements

• 24.1: THE Performance_Configuration SHALL support eager checkpointing mode
• 24.2: THE Performance_Configuration SHALL support batched checkpointing mode
• 24.3: THE Performance_Configuration SHALL support optimistic execution mode
• 24.4: THE Performance_Configuration SHALL document the default behavior and trade-offs

Variants

Eager

Checkpoint after every operation for maximum durability.

This mode provides the strongest durability guarantees but has the highest overhead due to frequent API calls.

Characteristics

• Every operation is immediately checkpointed
• Minimal work lost on failure (at most one operation)
• Higher latency due to synchronous checkpointing
• More API calls and higher cost

Use Cases

• Financial transactions
• Critical business workflows
• Operations with expensive side effects

Requirements

• 24.1: THE Performance_Configuration SHALL support eager checkpointing mode

Batched

Batch multiple operations before checkpointing for balanced performance.

This is the default mode that provides a good balance between durability and performance. Operations are grouped into batches based on size, count, or time limits before being checkpointed together.

Characteristics

• Operations are batched before checkpointing
• Some operations may be replayed on failure
• Better performance than eager mode
• Configurable batch size and timing

Use Cases

• Most general-purpose workflows
• Workflows with moderate durability requirements
• Cost-sensitive applications

Requirements

• 24.2: THE Performance_Configuration SHALL support batched checkpointing mode

Optimistic

Execute multiple operations before checkpointing for best performance.

This mode prioritizes performance over durability by executing multiple operations before creating a checkpoint. On failure, more work may need to be replayed.

Characteristics

• Multiple operations execute before checkpointing
• More work may be replayed on failure
• Best performance and lowest cost
• Suitable for idempotent operations

Use Cases

• High-throughput batch processing
• Workflows with cheap, idempotent operations
• Performance-critical applications

Requirements

• 24.3: THE Performance_Configuration SHALL support optimistic execution mode

Implementations

impl CheckpointingMode

pub fn is_eager(&self) -> bool

Returns true if this mode checkpoints after every operation.

pub fn is_batched(&self) -> bool

Returns true if this mode batches operations before checkpointing.

pub fn is_optimistic(&self) -> bool

Returns true if this mode executes multiple operations before checkpointing.

pub fn description(&self) -> &'static str

Returns a human-readable description of this mode.

Trait Implementations

impl Clone for CheckpointingMode

fn clone(&self) -> CheckpointingMode

Returns a duplicate of the value.

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

Performs copy-assignment from source.

impl Debug for CheckpointingMode

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

Formats the value using the given formatter.

impl Default for CheckpointingMode

fn default() -> Self

Returns the default checkpointing mode (Batched).

Batched mode is the default because it provides a good balance between durability and performance for most use cases.

impl<'de> Deserialize<'de> for CheckpointingMode

fn deserialize<__D>(__deserializer: __D) -> Result<Self, __D::Error>

where __D: Deserializer<'de>,

Deserialize this value from the given Serde deserializer.

impl PartialEq for CheckpointingMode

fn eq(&self, other: &CheckpointingMode) -> bool

Tests for self and other values to be equal, and is used by ==.

fn ne(&self, other: &Rhs) -> bool

Tests for !=. The default implementation is almost always sufficient, and should not be overridden without very good reason.

impl Serialize for CheckpointingMode

fn serialize<__S>(&self, __serializer: __S) -> Result<__S::Ok, __S::Error>

where __S: Serializer,

Serialize this value into the given Serde serializer.

impl Copy for CheckpointingMode

impl Eq for CheckpointingMode

impl StructuralPartialEq for CheckpointingMode