In the spirit of #62, this ticket tracks the considerations for implementing a storage adapter for Amazon DynamoDb; It absolutely does not represent a roadmapped task or anything that's an organic need relevant to a current usage scenario.

The scheme used by Equinox.Cosmos seems to map to the [new DynamoDb transactional API) (https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/transaction-apis.html)

Not 100% about how best to manage OCC - the client Position tracks the etag in the Cosmos impl, and a detailed read and research of guarantees provided is obviously warranted. One thing that does seem clear is that it It seems the client token idempotency is definitely not relevant. Wild guess: Maintaining expectedVersion either inside Tip or as metadata within it and then doing the writes conditional on that should work.

One key difference is the 400K document size upper limit, which means:

• Unfolds can't practically be maintained directly in Tip - e.g. if you ever need to support a transition in a snapshot schema in a blue/green deploy scenario, that halves the 400K. This means that an equivalent of Cosmos: Provide ability to separate storage of snapshots #61 would need to be implemented
• Likely one should explore re-introducing the [Tip isa Batch] semantics removed in Remove Tip isa Batch semantics #58 as that is in general an efficient scheme in terms of reducing document counts, contention and Request Capacity Init consumption Should follow the Equinox.CosmosStore v3 impl, which implements Tip isa Batch semantics
• The 400K may make Provide practical default Event size limit checks at storage level #31 more relevant than it has proven for CosmosStore - client side mechanisms about managing how one is faring wrt the limit will be big consideration given its 3MB vs 400K - the former is effectively unlimited for most reasonable sets of events and/or unfolds one might be maintaining.