1) The only peer guaranteed to have been updated is the peer requesting the transaction. The others will eventually see the change. If your application requires peer coordination, you need to use the blocking (sync connection t)
function to achieve it. For more information, see datomic-docs.
2) The transactor broadcasts new changes to all connected peers. The peers state is composed of the novelty coming from the transactor and the data segments they retrieve directly from storage. Again, the sync
function can communicate with the transactor to ensure that a peer blocks until all transactions written before the call to sync
are available. Most other functions do not communicate with the transactor or block.
3) If your system doesn't require huge write scalability and your application data tends to fit in memory, then the choice of a particular storage service is generally irrelevant except, of course, for their operational capabilities (backups, admin tools, etc.) which have nothing to do with Datomic. See How does the storage backend influence Datomic? for more details.