Improve DynamoDB Performance with DAX

Summary

This video introduces DynamoDB Accelerator (DAX), a managed caching layer for DynamoDB that offers microsecond-level performance, significantly faster than standard DynamoDB operations. The script covers DAX's use cases, benefits, and limitations, including eventual consistency issues. It also provides an in-depth look at DAX's architecture, explaining how it handles read and write operations, and concludes with best practices for monitoring, scaling, and avoiding common pitfalls when using DAX in applications.

Takeaways

• 🚀 DynamoDB Accelerator (DAX) is a fully managed caching layer for DynamoDB that improves performance by providing microsecond response times.
• 💡 DAX is suitable for applications with consistent or burst traffic on the same set of keys, especially those with limited write patterns.
• 📊 Caching optimizes performance by storing frequently accessed data in memory, reducing the need for repetitive database queries.
• 🔄 DAX supports various operations including get, query, scan, update, delete, and put, as well as LSI and GSI operations.
• 📈 DAX clusters consist of EC2 nodes that can be scaled horizontally (adding more nodes) and vertically (adding more resources to nodes).
• 🖥️ DAX clusters typically have one master node for writes and multiple read replicas to serve read requests.
• ⚠️ Using DAX introduces eventual consistency, meaning there could be a delay in data updates between the cache and the database, potentially serving stale data.
• 🔍 Avoid caching queries if you need consistent data, as the cached query results may not reflect the latest updates.
• 🔧 Monitor and scale your DAX nodes according to your application's workload to ensure optimal performance and cost-efficiency.
• 🔗 Sharing DAX clusters across multiple tables or applications can lead to cascading failures, so it's important to be cautious with this setup.

Q & A

What is DynamoDB Accelerator (DAX)?

DynamoDB Accelerator, also known as DAX, is a fully managed, highly available caching layer for DynamoDB that delivers microsecond-level performance for read and write operations.

What is the basic function of a cache?

A cache is a data storage layer that contains a subset of data from the main database. It serves to optimize performance by allowing for quicker data retrieval from in-memory storage rather than from the database itself.

What is the difference between local and remote caches?

A local cache is stored in the memory of the machine it serves, while a remote cache involves multiple nodes working together to act as a distributed cache, similar to how DAX operates.

How does DAX improve performance compared to standard DynamoDB?

DAX improves performance by providing microsecond-level response times for read operations, which is significantly faster than the typical milliseconds range for standard DynamoDB get item operations.

What are the scalability options for DAX?

DAX is both horizontally and vertically scalable. Horizontal scalability is achieved by adding more nodes to the cluster, while vertical scalability involves increasing the CPU, memory, or performance of the existing nodes.

Which operations does DAX support for data retrieval and modification?

DAX supports get, query, and scan operations for data retrieval, and update, delete, and put operations for data modification. It also supports caching for LSI (Local Secondary Index), GSI (Global Secondary Index), and any range key operations during queries.

What are the use case scenarios where DAX is suitable?

DAX is suitable for applications with consistent or burst-like traffic on the same set of keys, limited write patterns, and those requiring microsecond-level response times. It is also suitable for read-intensive applications that can tolerate eventual consistency.

What is the concept of eventual consistency in the context of DAX?

Eventual consistency means that there may be scenarios where the data in the DAX cache is inconsistent with the data in the DynamoDB table, leading to the possibility of serving stale content.

What is the recommended approach when using DAX for applications that require high data accuracy?

For applications requiring high data accuracy, it is recommended to use the DynamoDB table as the source of truth and avoid relying solely on the DAX cache, especially for critical operations.

What are some best practices when using DAX?

Best practices include understanding the implications of caching queries, monitoring and scaling nodes based on workload, being aware of single points of failure when sharing a cluster across multiple tables, and treating the DynamoDB table as the source of truth when in doubt.

What is the role of the 'item cache' in DAX?

The item cache in DAX is responsible for storing mappings of keys to values. It is updated transactionally whenever there are modifications to the items in the DynamoDB table, ensuring that subsequent lookups can be served from the cache.

How does the 'query cache' in DAX work?

The query cache in DAX works by caching a combination of criteria and a list of results. When a query request comes in, DAX first checks if the criteria have been previously queried. If not, it retrieves the data from DynamoDB and stores it in the cache for faster access in subsequent queries.

What is the potential issue with using the query cache in DAX?

The potential issue with using the query cache is that it may serve stale data. If any of the items in the cached results change in the DynamoDB table while the cache entry is still valid, the next query using the same criteria may receive outdated results from the cache.

Outlines

00:00

🚀 Introduction to DynamoDB Accelerator (DAX)

The video script introduces the concept of DynamoDB Accelerator, known as DAX, which is a highly efficient caching layer for DynamoDB. The speaker expresses excitement about discussing DAX due to their familiarity with it. The video aims to provide an overview of DAX, discuss its suitable use cases, explain its operational mechanism, delve into its inner workings, and conclude with best practice advice. Before diving into DAX, the script mentions a tool called 'Dino bass' designed to simplify working with DynamoDB, offering a free trial and a link in the description for further exploration. The foundation of the discussion is set by explaining the basic concept of caching, its benefits, and how it functions as an in-memory data storage layer to improve performance by reducing database retrieval times.

05:03

🛠 Understanding DAX and Its Scalability

This paragraph delves into what DAX is—a fully managed, highly available caching layer for DynamoDB that significantly boosts performance to microsecond levels. It contrasts the typical performance of DynamoDB with the enhanced performance provided by DAX. The script explains that DAX is scalable both horizontally and vertically, with nodes consisting of EC2 machines that work together to serve cached content. It clarifies that one node acts as the master for write operations, while others serve as read replicas. DAX supports common DynamoDB operations like get, query, scan, update, delete, and put, and also caches Local Secondary Index (LSI) and Global Secondary Index (GSI) operations. The transition from standard DynamoDB to DAX is straightforward, typically requiring only a change in the SDK and endpoint. The cost of using DAX is based on a per-node basis, with no additional costs incurred.

10:05

🤔 Assessing Suitability for DAX Use

The script discusses the suitability of DAX for different applications, noting that while DAX offers performance benefits, it also has limitations that may make it unsuitable for certain use cases. Ideal candidates for DAX are applications with consistent or bursty traffic on a set of keys that do not change frequently, requiring microsecond-level response times and being able to tolerate eventual consistency. Eventual consistency is explained as a scenario where data in the cache may become inconsistent with the DynamoDB table, leading to potential issues. The paragraph advises against using DAX for write-intensive applications, as caches are more beneficial for read-intensive scenarios with high read and limited write operations.

15:06

🔍 Deep Dive into DAX's Internal Mechanisms

The script provides an in-depth look at how DAX operates, starting with a high-level overview of setting up a DAX cluster in front of a DynamoDB table to reduce read capacity costs and improve performance. It explains the process of read and write operations within DAX, including cache misses and the propagation of data from the master node to read replicas. The paragraph then zooms in on the low-level implementation of DAX, detailing the two internal caches: the item cache, which stores key-value mappings and is updated transactionally with table modifications, and the query cache, which stores query results based on criteria. The script highlights the potential issues with query caching, such as serving stale data due to delays in updating the cache in response to table changes.

20:07

📘 Best Practices for Using DAX

The final paragraph offers best practice advice for using DAX. It warns against caching queries due to the risk of serving inconsistent data and emphasizes the importance of understanding the implications of using caches for mission-critical information. It also stresses the need for monitoring and scaling DAX nodes based on workload, as well as being cautious about sharing a DAX cluster across multiple tables to prevent potential cascading failures. The advice concludes with a reminder to always consider the DynamoDB table as the source of truth in cases of doubt, to ensure fault tolerance and the best possible user experience.

📺 Conclusion and Future Content Tease

The video script concludes with a prompt for viewers to like and subscribe to stay updated with upcoming content, including a teaser for a future video on DynamoDB schema design. The speaker thanks the audience and signs off, indicating the end of the current video session.

Keywords

💡DynamoDB Accelerator (DAX)

DynamoDB Accelerator, known as DAX, is a fully managed, highly available caching layer for DynamoDB that delivers microsecond-level performance. It is a core subject of the video, which discusses its benefits, use cases, and how it works. The script mentions DAX's ability to significantly improve the performance of get item operations, which typically take several milliseconds in DynamoDB, to a much faster microsecond level.

💡Caching

Caching is a fundamental concept in the script, defined as an optimization technique that stores a subset of data in memory for quicker retrieval. The video explains that caching reduces the need to access the database repeatedly for the same data, thus enhancing performance. The script uses the example of a country database to illustrate how caching can save a trip to the database for faster data retrieval.

💡In-memory Cache

An in-memory cache is a data storage layer that resides in the RAM of a local machine, allowing for rapid data access. The video script discusses how in-memory caching, such as with DAX, can provide faster performance for data retrieval operations compared to accessing data directly from a database. It is a key component of how DAX achieves its high-speed performance.

💡Dino Bass

Dino Bass is an application mentioned in the script that is designed to ease the process of working with DynamoDB. It includes features for performing tedious tasks and visualizing data intuitively. The script suggests that Dino Bass can be a helpful tool for users working with DynamoDB, offering a seven-day free trial for users to evaluate its usefulness.

💡Microsecond-level Performance

The term 'microsecond-level performance' refers to the extremely fast response times provided by DAX, which is a significant improvement over the typical millisecond response times of DynamoDB. The video emphasizes this performance boost as a key advantage of using DAX for read-intensive applications.

💡Horizontal and Vertical Scalability

Horizontal and vertical scalability are concepts related to the ability of a system to handle increased load by adding more resources. In the context of the video, DAX is described as scalable both horizontally, by adding more nodes to a cluster, and vertically, by enhancing the capabilities of existing nodes with more CPU, memory, or faster-performing memory.

💡Eventual Consistency

Eventual consistency is a concept where data may not immediately reflect the latest updates across all copies. The script warns about the implications of eventual consistency when using DAX, as it can lead to scenarios where the cache serves stale data. This is a critical consideration when deciding if DAX is suitable for an application that requires up-to-date data.

💡Read Replicas

Read replicas are copies of the data that can handle read requests in a database system. The video script explains that in a DAX cluster, one node acts as the master for writes, while other nodes serve as read replicas, providing the ability to distribute read requests and enhance performance.

💡Item Cache

The item cache is one of the two internal caches maintained by DAX, as detailed in the script. It stores mappings of keys to values, ensuring that get item operations are served quickly from the cache. The script uses the item cache to illustrate how DAX maintains consistency between the cache and the DynamoDB table during updates.

💡Query Cache

The query cache is the second type of internal cache in DAX, which is responsible for caching results of query operations. However, the script cautions against its use due to the potential for serving stale data. The video explains the mechanics of the query cache and why it can be problematic, especially when updates occur on the DynamoDB table that are not immediately reflected in the cache.

Highlights

Introduction to DynamoDB Accelerator (DAX) and its ability to significantly improve performance for DynamoDB operations.

DAX, also known as DynamoDB Accelerator, is a fully managed, highly available caching layer for DynamoDB.

DAX delivers microsecond-level performance, a stark contrast to the typical millisecond response times of DynamoDB.

DAX's scalability allows for both horizontal and vertical scaling to meet varying performance demands.

DAX's node architecture consists of a master node for writes and multiple read replica nodes.

DAX supports common DynamoDB operations like get, query, scan, as well as update, delete, and put.

The introduction of Dino Bass, a tool designed to simplify working with DynamoDB and visualize data.

Caching basics explained, including the concept of a cache as a data storage layer containing a subset of data.

The importance of caching for optimizing database operations and reducing round-trip costs.

DAX's use case suitability for applications with consistent or burst-like traffic on the same set of keys.

Limitations of DAX, including eventual consistency and scenarios where data in the cache may be stale.

Best practices for using DAX, emphasizing the importance of understanding eventual consistency implications.

The recommendation to monitor and scale DAX nodes based on workload to optimize performance and cost.

Potential issues with sharing a DAX cluster across multiple tables and the risk of cascading failures.

The advice to use DynamoDB as the source of truth and not rely solely on DAX for critical data operations.

An overview of how DAX works internally, including the item cache and query cache mechanisms.

The problem of serving stale data from the query cache due to delays in updating the item cache.

The conclusion emphasizing the need for fault tolerance and delivering the best experience for customers when using DAX.

Transcripts

hello everyone this is the video where I

tell you about dynamo DB accelerator

which is also known as Dax and I got to

tell you I'm really super excited about

this video because I've used Dax quite a

bit in the past so I'm quite familiar

with some of the low-level details that

I'm very excited to share with you today

so this video is gonna consist of an

overview of what Dax is a small talk

about what use cases Dax is suitable for

followed by an overview of how it works

than a deep dive on how it works and

finally some talk about best practices

but before I get into that I just

briefly want to mention a neat tool I

came across when working with dynamo DB

and the tool it's called Dino bass Dino

bass is an application that's devoted to

making your life easier when working

with dynamo DB how it includes features

that allow you to perform some normally

tedious dynamo tasks as well as

visualize your data in a pretty

intuitive way and Dino bass has a seven

day free trial so I recommend you try it

out to see if it's right for you you can

find a link in the description section

below so now getting into the meat of

the video I really want to just jump

right into Dax but before we do that I

think we need to set the stage and

quickly talk about what caching is at

its most basic level so first let's talk

about what is a cache why is it useful

so a cache is in its most basic form

it's just a data storage layer that

contains a subset of your data so

imagine you have a country database

where you have country IDs and then some

details about those country objects

typically when we try to retrieve data

from a database there's a round-trip

cost of making that connection to the

database making the query and finally

getting those results back caching is an

optimization technique that allows for

duplication of this data and that

duplicated data sits in memory typically

on a local machine and instead of

reading that data from the database

itself your application will have

business logic to first attempt to read

it from your in-memory cache before you

go and get it from the database so it

essentially serves as a mechanism to

save a trip to the database and deliver

some quicker performance for your get

operations so like I mentioned a cache

entry is usually stored in memory

to quickly retrieve and serve content

and caches can be local or remote you

can have just a local cache that's

serving memory directly our that machine

you can have a remote cache which is

something more similar to how Docs works

where you have multiple nodes that are

working as a unit to act as a cache and

we're gonna get more into those details

later so Before we jump into Dax

specifically let's just go over again

how this works

so say for instance you have an ojs app

and that's hosted on an ec2 machine in

AWS and you have requests that are

coming in for a country ID for instance

what your application would do is first

check your cache for the country ID

that's being queried on if the item is

in the cache it would serve it right

back right away if the item was not in

the cache then you would go to the

database retrieve that data there and

before you returned the row back to the

caller

you put that row in the cache so that

next time when a retrieval operation

comes in that row will be in the cache

so you don't have to make another trip

to the database they got the record

again finally to return that value back

to your clients so this was a brief

overview about how caches work but the

next logical question is how does Dax

fit into this whole picture

we know that Dax is for optimization we

know DynamoDB is a database

what does Dax do and how does it make my

life easier I'm sure you're all asking

this question now so what is Dax

so Dax is a fully managed highly

available caching layer for dynamodb it

delivers microsecond level performance

and if you've worked with dynamo in the

past you know that a typical level of

performance that you get on a getitem

operation is something in the realm of

five to eight milliseconds I would say

on the lower end and if you're doing

something a bit more bulky with query

operations that are retrieving multiple

rows then maybe like a couple hundred

milliseconds maybe 50 milliseconds if

you're lucky but that's the kind of

performance that you're going to get out

of normal and DynamoDB Dax takes that to

the next level and delivers microsecond

level performance for you so you

definitely get a boost in the

performance department at the cost of

some limitations of

Dax and that's what I want to kind of

talk about in the next few slides here

so Dax is horizontally and vertically

scalable and like I mentioned Dax

consists of nodes and each node is an

ec2 machine and a Dax cluster works

together with these nodes that are in

the cluster to serve some highly

available content that's duplicated

across all of your notes so Dax is

horizontally scalable in the sense that

you can easily add more nodes to your

cluster and it's vertically scalable in

the sense that you can throw more CPU or

more memory or faster performing memory

also at your nodes to improve

performance in the vertical dimension

just keep in mind one node will always

serve as your master which is the ledger

for writes and the other nodes that are

in your cluster will serve as your read

replicas and we'll get more into that in

the next few slides as well so Dax by

default supports get query and scan

operations on the data retrieval side

and update delete and put operations on

the data modification side it also

supports caching for LSI GSI operations

and any range key operations that you're

doing when performing queries it allows

for easy migration from just your

standard vanilla DynamoDB to Dax

typically you just have to switch out

your SDK that you're using and then you

just switch the endpoint to point to the

Dax cluster as opposed to the Dynamo

table and finally like I was mentioning

before your cache is hosted on multiple

nodes in a cluster which are actually

just memory optimized ec2 instances and

the cost model is that you just pay per

node there's no additional costs that

are incurred as a result of using Dax

you just pay for the hardware so now I

want to move on to what applications is

Dax suitable for because like I

mentioned it gives you all these

performance boost it's all does all

these great things for you makes things

really fast so you can do all this

optimization in your application but

unfortunately all this performance boost

does come at a cost and the limitations

that arise out of using Dax sometimes

make it such that certain applications

are suitable candidates so let's talk a

little bit about that so when should you

use it when should you not use it

so you should use it if you have an

access pattern such that you have

consistent or burst like traffic on the

same set of keys ideally those keys

don't change very often so you have

limited write patterns on those keys

also obviously I've kind of mentioned a

lot about performance here so if you do

require that microsecond level response

times then you should definitely look

into using Dax I'm going to get more

into the limitations next thirdly if you

if your use case can tolerate eventual

consistency so what eventual consistency

means in pretty basic terms is that

you're going to have scenarios or cases

when you have data that exists for a

specific key on your DynamoDB table that

is inconsistent with what exists on your

cache so say for instance you have a

dynamodb table where your ID is ABC and

the value is 1 in your dynamic table

that's the rollout as it as it exists

ABC with value 1 it's possible due to

the way that Docs works that if that row

gets modified the modification may not

propagate into the Dax cluster so that

when a query takes place on the Dax

cluster it will potentially be serving

up stale content so this is one of the

limitations that you have to factor in

when you're deciding whether or not you

want to use it because this can cause

some very very difficult to debug

scenarios and if you're not aware of it

from the get-go it'll cause some very

complex bugs in your application and

finally you should use it when your

application is read intensive and not

write intensive like I kind of alluded

to before you have one master with

multiple read replicas if you have a

very read intensive application your

master node will very quickly become

overburdened with traffic and write

intensive applications just don't really

make sense for caches caches are

typically used for applications with a

lot of reads and accesses on your data

with not a lot of writes so so far we've

talked about what caches are what Docs

is a little bit about how it works and

kind of if your use case is suitable for

it now I kind of want to jump into a

little bit of an overview to start about

how

DOX works under the hood followed by a

more comprehensive deep dive and that'll

kind of really show you some of the

low-level details about why eventual

consistency can be problematic for

applications so let's move on now into

how it works from an overview so say you

have a transactions table and this

dynamo table stores credit card

transactions in this case and say you

decide to set up a Dax cluster that's

going to sit in front of your dynamo

table because for whatever reason you

have a very high reed pattern on this

table and your read capacity usage is

starting to get expensive right you

don't want to be paying 10000 read

capacity units on your transactions

table you're looking for something

that's going to be cheaper and also give

you a performance boost so you say okay

let's use a Dax cluster so you set up

your docks cluster in the console and

say we specify three nodes in our Dax

cluster by defaults Dax will assign one

to be the master and the other two nodes

to be read replicas which are going to

contain copies of the masters cache so

behind the scenes any rights that occur

will automatically first go to the

master and then propagate their data

into the read replicas so you have this

very natural sharing of information

that's going on between the nodes in

your cluster so Dax will also set up a

load balancer with an endpoint so that

whenever a request comes in it's kind of

a round-robin approach into determining

which node is going to actually serve

the request could be your master it

could be one of the other two reed

replicas so say for instance if a

request comes in to your cache and say

it's a read operation so you're trying

to find maybe

transaction ID t1 let's just write that

down you're looking for t1 in your

transactions table how is that going to

work so you query t1 against the Dax

endpoint you're gonna check the cache to

see if t1 exists in the cache cluster

and the case that it does you just

return it back to the client right away

in the case that it doesn't you need to

go and retrieve that data from your

transactions table so it'll go and query

your dynamo DB database retrieve that

data insert it into your docks

so that it's available for our next

query that comes in before finally

returning it back to your clients so

that's how it works from the read

perspective we had two operations we had

what we call a cache miss when we found

out that the entry didn't exist in the

cache and then we had to go and retrieve

it from the source of truth before we

populated it so that was the read flow

so how does it work for the right flow

so for the right flow if there's a right

to your DynamoDB table that write will

be transactional in nature your first

write will occur on the Dynamo table

itself the second step to be performed

is to write that same row into your

cache so you get that data primed in

your cache because in all likelihood if

you're writing an item to your table

it's very likely that you're gonna read

that item from that table shortly

thereafter so that's the right flow of

how data gets into the cache when data

is modified in the source of truth so

that was a quick overview from a

high-level perspective

now let's talk about the low-level

implementation of Dax and how it works

from the most basic levels so how it

works from the advanced perspective so

again we have our transactions table and

say we decide to set up our cluster

again and this is kind of a zoomed in

view of a Dax cluster say we're just

looking at a particular node say it's

our master node in this case just to

make our lives a little bit simpler so

behind the scene Dax will maintain two

sets of internal caches that are shared

across your Dax cluster so the first one

is called an item cache and the item

caches responsibility is to store

mappings of keys to values so your keys

being the ID of the item and the value

being the item itself

so if you add t1 that's the key in this

example and the contents of that row say

it's a purchase transaction and it's a

$50 value and it took place on a certain

date all that metadata is the value so

we have a mapping between the key which

was t1 and the value or the object which

is a transaction in this case so the

intention of this cache is to maintain

this mapping whenever updates occur on

your

table so say for instance if a request

comes in it's a get item API and it's

pointed to your docs cluster say our

we're using c1 here that's our partition

key and our range key is date we will

first like I mentioned before attempt to

see if it's in the item cache if it's in

the cache we return right away if it's

not we go and look up that item in the

dynamo table before we finally store it

in our item cache with the c1 and date

hashed as the key and the actual value

stored alongside that hash key so that's

the item caches responsibility so

anytime any get item operations occur

they're gonna always look at the item

cache and any time any modifications

occurred to the items on your table

they're gonna be transactionally updated

into your item cache so the next time a

lookup occurs that value will be sitting

in your item cache so the second cache

that occurs is what's called the query

cache and the query cache is what drives

as you would expect your query

operations but it works in a similar but

also a very different way so the query

cache consists of an a mapping between

an ID and a list of objects because as

we know when we submit a query we submit

a key that we're interested in and also

a criteria in the range key case maybe

it's your range key is date and you only

want things that are within the last

seven days so how the query cache works

is slightly different so when a request

comes in with this combination say c1

plus a date criteria the same flow of

operations will happen will first look

into the cache see if we have this

combination of criteria ever queried for

before if we don't then we'll go and

retrieve that data and it finally will

store that data inside the cache for

later use so if someone calls again

within the next 5 minutes or so then

we'll just retrieve from the cache a B

and C and serve up that data very very

quickly so obviously with this

implementation you get very exceptional

performance you don't have to actually

perform a query on your dynamo table

instead you're just looking in a cache

and it's an over the 1 lookup so you get

that data

back right away but I've encouraged you

to do a thought exercise here about why

this is a problem and maybe you want to

pause it to think about it a little bit

because these rows right they're

replicated a b and c they're replicated

in the query cache the a is also

replicated in the item cache and then we

have a transactions database which is

the authority on this data so I want you

to pause for a second if you can try to

think of a scenario when you update

items in this table problems with what

data you serve back so maybe you want to

take a pause take a minute or so to

think about that right now so hopefully

you thought about this problem and let's

walk through why this set up is an issue

and why you should probably never be

using query caches so think about this

case write the set up that I've already

described to you we had a previous

lookup where we did see 1 and 8 and we

retrieved item aim okay

we've already recognized the fact that

if a update occurs on the Dynamo table

there is a delay between when that

update is in the Dynamo table and when

that update is reflected in the item

cache right so that's problem number one

there's an inherent delay between these

two tables that problem is enhanced in

the query cache scenario because what

query cache is do is they cache a

criteria and a list of results so if any

of these results if a B or C changes

while this row exists in your query

cache then the next time a query comes

in for C one plus this specific criteria

this data may have already changed on

the DynamoDB table and you will never

know it so this is part of the reason

that caches on the query side are very

very ill-advised you have the very high

likelihood to serve up stale data so be

very very careful about working with

caches when you're using queries so this

was a more in-depth look about how it

works behind the scenes now I kind of

want to go into best practices things

you should know about when you're using

Dax or maybe you're thinking about using

it in your next project so the first one

is directly tied to my previous point

and that's to

don't cache queries unless you

understand the implications so

understand that you may have

inconsistent data if you're using your

dynamo table as a source of truth that

is for some very mission critical

information maybe it's like credit card

transactions then you don't want to be

using query caches you may not even want

to use caches in general since by

definition they introduced eventual

consistency a second one is from the

monitoring perspective and insta monitor

and scale your notes accordingly based

on workload as you know you're using ec2

machines you're paying for that

always-on functionality I don't think

there's auto scaling for Docs yet but if

there is there'll be a great new feature

but as a result you really need to

monitor your usage pattern I would

suggest starting with the lowest level

type of hardware see if that fits your

use case and then maybe you can add more

nodes to serve as read replicas or beef

up your replicas to be more intensive so

they can serve more traffic and the

third point is to be aware of single

point of failures if you decide to share

your cluster across multiple tables this

is a kind of a neat feature you can sit

you can share your cluster across

multiple DynamoDB tables so you can

store all amounts of data in there and

they could be totally unrelated the

problem with this is that if you're

sharing this across different services

or different use cases it's possible

that a read or write access pattern to

one table can cause a cascading failure

in your cache that can all of a sudden

start impacting your other application

that happens to also use the cache but a

different section of the cache

however if it starts failing it doesn't

matter failures failure there's no

section so failure there's no partition

you know failure it's either up or down

right so in this case you can have

certain parts of your application

impacting other parts of your

application so just be aware of doing

this if you decide to take this kind of

shortcut and the final one which has to

do with eventual consistency is when in

doubt use your dynamo to be record as

the source of truth don't perform

operations where you read from the docs

cluster use it as a source of truth and

then write to your dynamo table like we

said there's eventual consistency so the

likelihood of that data being out of

date at some point is no I don't want to

say hi but it's

possible so keep that in mind when

you're designing your application be

fault tolerant but also try to deliver

the best experience possible for your

customers

so hopefully you like this video I have

many more on dynamodb including this one

on the right here about DynamoDB schema

design also please don't forget to Like

and subscribe so that you don't miss out

on next week's video thanks so much

folks and I'll see you next time