anchor.diff:    with FrontendIdentifier, it also uniquely identifies any transaction that has
     ever executed in the cluster, e.g. forming a GlobalTransactionIdentifier.
   
  -== Frontend persistence
  +== Persistence model
  +
  +=== Frontend persistence
     As noted above, implementation of the Frontend Generation requires each member
     to persistently store a single 64 bit counter. To keep the persistence interfaces
     within a member consistent, Frontend uses Akka Persistence to maintain this
  
positive.code:   by the application and enough metadata about Local Histories and Transactions
    to make state recovery across shard leadership movement possible.
  
  === User Data persistence
    The Snapshot needs to identify all transactions which have been integrated
    into it. Enumerating all of them is clearly not practical, hence we exploit
    the monotonic nature of identifiers' relationship to Global History. For each
  
negative.code:   it being completed. If an inconsistency occurs (due to messages getting lost
    or Shard Leader failing), the Frontend will retransmit this state to the Backend.
  
  === Backend persistence
    The Backend needs to persist and replicate enough state to ensure that Shard
    Leader movement does not render Local Histories inoperable, as that has
    a direct impact on applications, which need to have a state reconciliation
  