‫So, a quick lecture on something
‫called DynamoDB Write Sharding.
‫So, let's assume this use case
‫where we have a voting application,
‫and voting application people can vote
‫for candidate A and candidate B.
‫So, two candidates.
‫Now, if we used the partition key to be candidate ID,
‫the problem is that all the results
‫will go into two partitions only
‫because, well, the data is going to be partitioned
‫by either candidate A or candidate B,
‫which will generate issues for writes and for reads
‫so we're gonna get hot partition issues.
‫So, how do we solve this issue?
‫Well, a strategy is to distribute the candidate ID
‫better across partitions and to do so,
‫we're going to add a suffix,
‫or a prefix to the partition key value.
‫So, the idea is that we're now we're going to get
‫the candidate ID, and then we'll add,
‫for example, the number 11.
‫So candidate a 11, and add a row,
‫and then we're going to have candidate b 17,
‫candidate b 18, candidate a 20,
‫and the idea is that now the partition key,
‫is a lot more distributed,
‫because it takes more unique values
‫and therefore your data set is going to be fully written
‫and fully readable from your Dynamo DB table.
‫Now, two methods for creating this suffix or this prefix.
‫You can use a random suffix
‫or you can calculate it using a hashing algorithm.
‫Both of these things work.
‫The idea is that you want to get a very,
‫very distributed partition key.
‫That's all, it's just a theory lecture,
‫but you know this strategy now.
‫I hope you liked it and I will see you in the next lecture.