However you can switch between the two – so, in the example above you would use Provisioned capacity normally, but on expected spikes like Black Friday you could switch to On-demand mode and then back again after the bursty period has ended.To Summarize:Before designing your data model, identify and understand the access patterns/use cases the table has to serveFor a given access pattern, the data model should ideally ensure that any read/write operation will hit no more than one partitionEven though DynamoDB splits the table data evenly among its Partitions, depending on the context, the choice of Partition Key could lead to “hotspotting” and throttling of requestsAvoid “hotspotting” by choosing partition keys with good cardinality and adding salt values to the partition key, if neededArchive, delete or expire old/unused data..If you have large volumes of outdated/unused data in your table, you could be paying several times the cost of your actual usageIf you are planning to access your table from different geographic regions, consider using Global tables..Within a given region, Global table read and write performance should not be different from the performance of a standard table..But for multi-region requests, Global tables would be much fasterGlobal tables are more expensive than Standard tables due to the additional writes involved in replication, write pricing in terms of rWCU, inter-region data transfer costs and additional storage requirementsWhile On-demand Capacity Mode is a great addition to the existing features, it might not be the best mode of operation for all workloads..Throttling is still possible in this mode.There is no replacement for proper capacity planning and good data modelingI hope this article gave you a reasonable insight into designing data models for DynamoDB tables.The next article — part 4 of this series will focus of the guidelines to be followed for faster reads/writes in DynamoDB.. More details