Concurrent Cairo Transactions: Storage Write Batching vs Memory Caching Trade-offs

Assuming a recent Cairo compiler and StarkNet sequencer version, storage access to the same key under concurrent requests introduces latency that is absent in single-request execution because StarkNet orders transactions sequentially. The language specification does not define isolation levels for concurrent transactions, leaving unclear whether competing storage writes to the same key are serialized or resolved as last-write-wins.

Developers face a concrete design choice: batch multiple storage writes into a single transaction to reduce contention and preserve consistency, at the cost of higher gas per transaction; or cache critical reads in memory and defer storage writes to a later transaction, lowering immediate read latency but risking inconsistency if the deferred transaction fails. No standard Cairo pattern currently manages this trade-off.

Given that the specification does not state cross-transaction atomicity semantics for global state updates, which documented approach offers a safer default for high-throughput contracts under current StarkNet ordering rules, and what practical verification should precede relying on either batching or deferred writes?