# Cross-Call State Persistence

To sustain platform interactions across separate mobile connections, **Asterisk 2** syncs volatile variables into highly durable database layers. The architecture persists user keys to preserve continuous operational states.

---

## Multi-Session Data Lifecycle Topology

The chart below details how transient variables transfer into long-term caching systems to support disconnected user access:

```mermaid
graph LR
    %% Primary Call
    subgraph OriginCall["First Telephony Session"]
        WriteAction["Set Persistent Key<br/>(Action: SaveUserStep, Val: 'AccountVerified')"]
    end

    %% Central Storage
    subgraph CacheLedger["Distributed Datastore"]
        DbStore[("Redis Cluster Hash<br/>(TTL Configured: 604800 Seconds)")]
    end

    %% Secondary Call
    subgraph ReconnectCall["Subsequent Telephony Session"]
        ReadAction["Query Historical User Step<br/>(Skips duplicate authentication prompts)"]
    end

    %% Links
    WriteAction ==>|"Persist Attribute"| DbStore
    DbStore ==>|"Load Context String"| ReadAction

    %% Rich Styled Layout Themes
    classDef callToken fill:#0f172a,stroke:#38bdf8,stroke-width:2px,color:#fff,rx:6px,ry:6px;
    classDef dbToken fill:#312e81,stroke:#ec4899,stroke-width:2px,color:#fff,rx:6px,ry:6px;

    class OriginCall,WriteAction callToken;
    class CacheLedger,DbStore dbToken;
    class ReconnectCall,ReadAction callToken;
```

---

## Persistent Database Blueprint

### 1. Time-To-Live Expiration Fences
To keep database storage rows optimized, permanent session mapping records append programmatic TTL drop parameters (`7 days`). Expired customer variables purge cleanly during background storage maintenance sweeps.

### 2. Atomic Multi-Key Updating
Storage drivers bundle write requests inside strict single transactional execution instructions. This completely avoids intermediate state conflicts during distributed processing scenarios.