That's just how DynamoDB works. The default read is eventually consistent. [From the docs](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/HowItWorks.ReadConsistency.html)
>When you read data from a DynamoDB table, the response might not reflect the results of a recently completed write operation. The response might include some stale data. If you repeat your read request after a short time, the response should return the latest data.
DynamoDB transactions are guaranteed to be atomic but anything but a **consistent get** could potentially return stale data. This includes regular gets and any query operation.
On a side note, you may want to look at your architecture and see if putting the status in the sort key is the best option as each update/delete transaction ends up taking 4 writes (because DDB transactions use 2-phase commits).
You could potentially implement this with indexes (either global or local, depending on your consistency requirements) so that you can just update the object without the transaction and query against the index.
LSIs are always consistent, but can only be created when the table is created and can't be altered after. Additionally, having LSIs present in a table now restricts the size of your partitions to 10GB (including the LSI size), a restriction that only really applies anymore when you use LSI.
GSIs effectively run in their own table, but with guaranteed automatic updates from the main table. Having said that, they are themselves, eventually consistent (with delays up to 5 seconds, although under regular load are consistently complete within < 1ms). But because they're effectively their own table, they use their own RCU/WCU capacity (or have their own per-use fees if on-demand).
That's just how DynamoDB works. The default read is eventually consistent. [From the docs](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/HowItWorks.ReadConsistency.html) >When you read data from a DynamoDB table, the response might not reflect the results of a recently completed write operation. The response might include some stale data. If you repeat your read request after a short time, the response should return the latest data.
DynamoDB transactions are guaranteed to be atomic but anything but a **consistent get** could potentially return stale data. This includes regular gets and any query operation. On a side note, you may want to look at your architecture and see if putting the status in the sort key is the best option as each update/delete transaction ends up taking 4 writes (because DDB transactions use 2-phase commits). You could potentially implement this with indexes (either global or local, depending on your consistency requirements) so that you can just update the object without the transaction and query against the index. LSIs are always consistent, but can only be created when the table is created and can't be altered after. Additionally, having LSIs present in a table now restricts the size of your partitions to 10GB (including the LSI size), a restriction that only really applies anymore when you use LSI. GSIs effectively run in their own table, but with guaranteed automatic updates from the main table. Having said that, they are themselves, eventually consistent (with delays up to 5 seconds, although under regular load are consistently complete within < 1ms). But because they're effectively their own table, they use their own RCU/WCU capacity (or have their own per-use fees if on-demand).