
Amazon DynamoDB Update – Global Tables and On-Demand Backup - polmolea
https://aws.amazon.com/blogs/aws/new-for-amazon-dynamodb-global-tables-and-on-demand-backup/
======
johnvega
Looks like a direct competition to Microsoft Azure Cosmos DB. Anyone care to
point out the top 3 differences?

~~~
sheraz
Maybe sorta kinda -- just a heads-up that CosmosDB can talk multiple API
protocols:

    
    
      - MongoDB
      - Cassandra
      - Graph API
      - Azure tables
      - DocumentDB
    

I've used the MongoDB version, and it works ok for the basic CRUD stuff. I
cant comment on aggregations, etc.

Not sure from a quick peek if DynamoDB does the same...

------
uji
It seems this service is targeted towards specific applications where write
traffic is somewhat independent between 2 regions. However, you can shoot
yourself in foot, if 2 regions are trying to update the same row, because of
eventual consistency.

------
ramshanker
>> You can now create tables that are automatically replicated across two or
more AWS Regions, with full support for multi-master writes, with a couple of
clicks. <<

Hamm, If I understand it correctly, REGIONS are no longer heavily isolated.

~~~
dastbe
I would say this offers global capabilities while preserving regional
isolation. you're composing the global table out of regional tables (which
replicate between each other), and you're still using regional endpoints. this
means that a failure with one region's table does not have impact on the
other.

this model does mean that certain things, like conditional expressions, are
less useful/useless because you could very well execute a conditional
expression against stale date.

~~~
siculars
If replication is synchronous it will cost you time.

If replication is asynchronous it will cost you freshness.

I'm not entirely sure what's implemented here, either way you need to pick.
It's not magic.

~~~
a-priori
Jeff Barr says in this article exactly how it works: when you make a write in
one region, it streams the updates to the other regions. Presumably this is
built on top of the DynamoDB Streams system. It tags the item update with a
timestamp, and in the event of a conflict the most recent wins.

So in the case of a partition where the update stream is delayed, other
regions can read and write to their local copy of the tables. They'll be
replicated when the partition is healed. You should design around the
possibility of conflicts, so that the 'last writer wins' resolution does what
you want and leaves the system in a consistent state.

It would be nice if it emitted an event when write-write conflicts occur, so
you can monitor that and possibly add your own conflict resolution logic to
patch things up afterward. It doesn't appear like this exists.

Yes, you sacrifice freshness. When healthy, regions are behind by ~1s. If you
need consistent writes then you can use one as the 'primary' region and do all
your writes there and use the others as read replicas. But it's better to
design your system to not require full consistency and do reads and writes in
the local region.

(Disclaimer: I work for Amazon, but not in AWS and have nothing to do with
this project.)

~~~
vkjv
Thanks for the info. Custom resolution in lambda with vector clocks would be
fantastic. Maybe in the future?

