14:05 when you say "transactionally" updated.. do you mean that it follows the pattern of a transaction, meaning commiting/reverting changes? ie: it adheres to the ACID properties? Also 15:55 - what do you mean by "the authority on this data"? Do you mean the ground truth of the data? as in: the most recent version of the data, the "latest" / "final" / "true" data?
Hey, I was going through the DAX client code, and it turns out that it supports all read and write operations of Dynamodb so in a way for a web server, the only point of contact is the DAX cluster. We fire all the read/write queries to the DAX client and it internally manages cache update and expiry so the problem that you mentioned may never occur at all
Hi Gautam, It isn't quite as simple to assume DAX 'manages the cache update and expiry'. There is still a threat of eventual consistency especially in failure mode scenarios where there is a delay between the time a record is committed to the cache and subsequently propogated into the dynamodb table. Also, if you have other threads/systems that are interacting directly with DynamoDB and bypassing the DAX cluster, the likelihood of stale data and eventual consistency is even greater.
@@BeABetterDev completely agree with your point but I meant that the DAX client is pretty smart to handle a lot of the hard stuff for you so that the dev doesn't have to get their hands dirty solving the low-level stuff. As a dev, if we make sure that all the services only connect with DAX as a proxy to Dynamo then we can sideline a great deal of complexity and be able to effectively solve the cache invalidation issues for most of the use cases. As far as eventual consistency is concerned there are various cache update strategies - write-through, write around, write-back etc. We could get around the problem by choosing the right write strategy.
I if you're looking to improve performance for your Dynamo DB table with cashing than DynamoDB DB accelerator is the correct choice. If you're looking for just general caching then redis with elastic cache would be better.
Hi Maaz, cloudfront is more for caching static assets such as html, css, js, img files, etc. DAX is for caching dynamodb records which tend to be object entities. Hope this clarifies.
Hi Vimal. To invalidate a key/value record you could simply write to it with null contents which will invalidate the record in DynamoDB. However keep in mind this approach will not work for cache's on Queries or Scans since the entire blob associated with the scan/query input will be cached. More details can be found here: docs.aws.amazon.com/amazondynamodb/latest/developerguide/DAX.consistency.html
I found this helpful. You can specify the TTL setting for the query cache when you create a new DAX cluster. DAX also maintains an LRU list for the query cache. The list tracks when a result set was first written to the cache, and when the result was last read from the cache. If the query cache becomes full, DAX evicts older result sets (even if they have not expired yet) to make room for new result sets. The LRU algorithm is always enabled for the query cache, and is not user-configurable. If you specify zero as the query cache TTL setting, the query response will not be cached.
14:05 when you say "transactionally" updated.. do you mean that it follows the pattern of a transaction, meaning commiting/reverting changes? ie: it adheres to the ACID properties?
Also 15:55 - what do you mean by "the authority on this data"? Do you mean the ground truth of the data? as in: the most recent version of the data, the "latest" / "final" / "true" data?
Thank you for explaination. It is very helpful.
Glad it was helpful!
Hey, I was going through the DAX client code, and it turns out that it supports all read and write operations of Dynamodb so in a way for a web server, the only point of contact is the DAX cluster. We fire all the read/write queries to the DAX client and it internally manages cache update and expiry so the problem that you mentioned may never occur at all
Hi Gautam,
It isn't quite as simple to assume DAX 'manages the cache update and expiry'. There is still a threat of eventual consistency especially in failure mode scenarios where there is a delay between the time a record is committed to the cache and subsequently propogated into the dynamodb table.
Also, if you have other threads/systems that are interacting directly with DynamoDB and bypassing the DAX cluster, the likelihood of stale data and eventual consistency is even greater.
@@BeABetterDev completely agree with your point but I meant that the DAX client is pretty smart to handle a lot of the hard stuff for you so that the dev doesn't have to get their hands dirty solving the low-level stuff. As a dev, if we make sure that all the services only connect with DAX as a proxy to Dynamo then we can sideline a great deal of complexity and be able to effectively solve the cache invalidation issues for most of the use cases.
As far as eventual consistency is concerned there are various cache update strategies - write-through, write around, write-back etc. We could get around the problem by choosing the right write strategy.
What’s better DAX or redis elasticache?
I if you're looking to improve performance for your Dynamo DB table with cashing than DynamoDB DB accelerator is the correct choice. If you're looking for just general caching then redis with elastic cache would be better.
Thank you very much! It seems I need DAX.
Can we cache getallitems from table?
Well done video, thank you.
Thanks Mike!
Awesome 👍
Glad you enjoyed and welcome to the channel!
Hello , what do you recommend cloudfront caching or DAX ?
Hi Maaz, cloudfront is more for caching static assets such as html, css, js, img files, etc. DAX is for caching dynamodb records which tend to be object entities.
Hope this clarifies.
@@BeABetterDev It does thanks
@@BeABetterDev last question , would you consider using dax with appsync ?
Isn't there some Cache invalidation mechanism?
Hi Vimal. To invalidate a key/value record you could simply write to it with null contents which will invalidate the record in DynamoDB. However keep in mind this approach will not work for cache's on Queries or Scans since the entire blob associated with the scan/query input will be cached. More details can be found here: docs.aws.amazon.com/amazondynamodb/latest/developerguide/DAX.consistency.html
@@BeABetterDev Many thanks for the Info and time taken to explain it to me.
I found this helpful.
You can specify the TTL setting for the query cache when you create a new DAX cluster.
DAX also maintains an LRU list for the query cache. The list tracks when a result set was first written to the cache, and when the result was last read from the cache. If the query cache becomes full, DAX evicts older result sets (even if they have not expired yet) to make room for new result sets. The LRU algorithm is always enabled for the query cache, and is not user-configurable.
If you specify zero as the query cache TTL setting, the query response will not be cached.
thank you!
thank you
You're welcome Hai!