What are Best Practices for Using Amazon DynamoDB?

Amazon DynamoDB is good fit for NoSql kind of data, if you have lot of relationships between different entities, then better off using MySql or RDBMS.

Do not use transactions that span across tables in Amazon DynamoDB, if there is any such strong need, then better use a RDBMS. You can achieve some sort of eventual consistency can be achieved in DynamoDB using SQS.

Correctly model your domain objects using Hash Key, Range Key, Local Secondary Index and Global Secondary Indexes.

Use Auto Scaling option of Amazon DynamoDB to dynamically increase provisioned throughput as the need arises.

Use atomic update operations to update shared records from multiple threads, this will save some cost and resources.

For handling spike in write operations, user some kind of Queue (either Amazon SQS or Redis), this will not only bring resiliency to the system but also reduce the cost.

Use Spring Retry to handle write failures. Spring retry gives flexibility of exponential backoff, which could be quite helpful under heavy load conditions.

Amazon DynamoDB is not a single fit for all your database needs. Use it only when you can afford the budget and requirements fit into NoSql world.

If your application has strong transcational needs as well as NoSql needs, better to use RDBMS for transactional work and NoSql for everything else. In microservices architecture, for example, you can partition the application into multiple microservices and then each microservice can pick either NoSql or RDBMS as per its business requirement.

Do not model data into dynamoDB from object relational mindset as we do it in RDBMS. Denormalizing data is the key concept in NoSql world. For example, if you want to store Tags with an Article, put them all into one object, one table rather than creating separate table for Article and Tags.