That was at least a chief use case spotlighted in the original Dynamo paper by Amazon that what the precursor to AWS’ DynamoDB paper.
Not to say that couldn’t be done with Postgres but of course they were dealing with insane scale on Amazon Day.
That was at least a chief use case spotlighted in the original Dynamo paper by Amazon that what the precursor to AWS’ DynamoDB paper.
Not to say that couldn’t be done with Postgres but of course they were dealing with insane scale on Amazon Day.
not that you're saying they don't, but some people might interpret your comment that way.
It depends on how DynamoDB is used[0]:
Transactional operations provide atomicity, consistency,
isolation, and durability (ACID) guarantees only within
the region where the write is made originally.
Transactions are not supported across regions in global
tables.
Granted, this likely handles most use-cases and the restriction enforced makes complete sense.0 - https://docs.aws.amazon.com/amazondynamodb/latest/developerg...
Using a key-value store for shopping carts can work for awhile, especially for the use-case you describe, but fails when system functionality grows beyond retrieving only by a cart ID.
And when using a persistent store which does not provide ACID capabilities, the system will ultimately have to enforce at least atomicity and consistency via server logic.
Either you manage your system so it never ever uses any other key than a cart ID (services have been running for decades keeping the same unique ID, that's not some unreasonable thing).
Or you migrate your data to match the completely wild new requirement, and taking costly steps to deal with a funfamental business change would be seen as reasonable in most orgs.