Mastering Global Scale: An In-Depth Look at DynamoDB Global Tables


Hey Reader ๐Ÿ‘‹๐Ÿฝ

DynamoDB is one of the most popular AWS services that requires minimal management. However, as Dr. Werner Vogels reminds us:

โ€œEverything Fails All the Time.โ€ โšก๏ธ

Therefore, even with managed services like DynamoDB, being prepared for a regional outage is important.

The good thing: with DynamoDB Global Tables, you can easily replicate tables across multiple AWS regions. This will not only help with region outages, but it will also ensure data is closer to clients which will reduce latency.

DynamoDB Global Tables

Global Tables replicate your data across regions, offering:

  1. โšก๏ธ Faster Data Access: Clients in different locations access data quickly.
  2. ๐Ÿ”ฅ Region Outage Preparedness: Your application remains accessible even if a region fails.

How They Work

Data replicates asynchronously across regions, maintaining availability. Conflict resolution uses a last-write-wins approach, operating on an eventually consistent model.

Note: This can lead to synchronization issues in multi-tenant applications!

Setting Up

Create a table in one region and enable replication to others via the AWS Console, CLI, or IaC tools. DynamoDB automatically handles the bidirectional replication process - you don't need to do anything else.

With SST v3, creating a table with enabled replication is as easy as this:

If replication is enabled, the streaming option is not optional. You need to enable it! ๐Ÿ’ก

Use Cases

Let's talk about the usefulness of Global Tables in-depth.

Multi-Region Applications

Global Tables are useful for applications that serve users in multiple regions, allowing them to access data quickly from the nearest location. This setup improves the user experience by reducing latency without needing to implement caching mechanisms.

As DynamoDB runs in a pay-per-use model and it works well together with other equally charged services like Lambda, having a multi-region setup often doesnโ€™t come with high additional costs. With services like Route 53 you can easily create a multi-region application that will automatically select the closest healthy region available.

High Availability & Disaster Recovery

Global Tables help with disaster recovery by keeping copies of data in different regions. If a region has an outage (or youโ€™ve deployed a broken update to that region), the latency-based records of Route 53 can automatically notice this and redirect requests to a health region, even if it is further away from the source.

Weโ€™ve written a detailed article about how to set this up in the past.

If you accidentally delete a replicated table (which is not easy to do), your data will still remain in the other regions.

Low-Latency Data Access

By replicating data across regions, Global Tables offer low-latency access for users worldwide. This is crucial for applications that need real-time data interaction. It achieves this without using complex caching techniques.

This architecture will always reduce response times by a few milliseconds because the application is closer to the users.

Challenges and Solutions

Everything has its challenges, and this is true for DynamoDB global tables as well.

Handling Data Conflicts

Conflicts can happen with concurrent writes in different regions. The simplest solution is to use only one region for write operations and treat all other regions as read replicas. The downside is that you'll lose multi-region high availability for writes. If the main write region goes down, your application will switch to read-only mode.

Data conflicts due to race conditions can happen in basically any multi-tenant application.

Stale Reads

Stale reads happen when an application reads data that hasn't been updated to show the latest changes because of replication delays. This can occur not only with DynamoDB global tables but with any data in a distributed system. It's also common in caches that aren't properly cleared.

In a multi-region setup with Global Tables, you can't completely avoid stale reads between regions.

However, to reduce stale reads in a single region (which can also occur!), you can use strongly consistent reads when possible. In DynamoDB, a strongly consistent read provides the most current data, showing all successful writes before the read. This ensures your application always gets the latest data, though it may result in higher latency and lower availability compared to eventually consistent reads.

Conclusion

DynamoDB Global Tables are a practical way to ensure your application remains available & responsive across multiple AWS regions.

By replicating data asynchronously, you can keep your application running smoothly even if one region experiences issues.

However, everything comes with a grain of salt ๐Ÿง‚: you do need to manage potential challenges like data conflicts and stale reads โœŒ๏ธ

โ€‹

โ€‹Tobias Schmidt & Sandro Volpicella & from AWS Fundamentalsโ€‹
โ€‹
Cloud Engineers โ€ข Fullstack Developers โ€ข Educators

You're receiving this email because you're part of our awesome community!

If you'd prefer not to receive updates, you can easily unsubscribe anytime by clicking here: Unsubscribe

โ€‹

Our address: Dr.-Otto-BรถรŸner-Weg 7a, Ottobrunn, Bavaria 85521

AWS for the Real World

Join our community of over 8,800 readers delving into AWS. We highlight real-world best practices through easy-to-understand visualizations and one-pagers. Expect a fresh newsletter edition every two weeks.

Read more from AWS for the Real World

Hey Reader ๐Ÿ‘‹๐Ÿฝ This issue will be about a recent real-world experience that just went off right with the new year! ๐ŸŽ‰ Once upon a time... ๐Ÿฆ„ It all started in September 2024 where Edgio, the main CDN provider we used for one of my large enterprise projects, filed for bankruptcy. Edgio was natively integrated into Azure, allowing you to use it without leaving the Azure ecosystem. It also featured a powerful rules engine (allowing for all kinds of conditions, redirects and rewrites) and didnโ€™t...

โŒ› Reading time: 13 minutes ๐ŸŽ“ Main Learning: How to Run Apps on Fargate via ECS ๐Ÿ‘พ GitHub Repository โœ๏ธ Read the Full Post Online ๐Ÿ”— Hey Reader ๐Ÿ‘‹๐Ÿฝ When building applications on AWS, we need to run our code somewhere: a computation service. There are a lot of well-known and mature computation services on AWS. Youโ€™ll often find Lambda as the primary choice, as itโ€™s where you donโ€™t need to manage any infrastructure. You only need to bring your code - itโ€™s Serverless โšก๏ธ. However, more options can be...

โŒ› Reading time: 10 minutes ๐ŸŽ“ Main Learning: Running Postgres on Aurora DSQL with Drizzle ๐Ÿ‘พ GitHub Repository โœ๏ธ Read the Full Post Online ๐Ÿ”— Hey Reader ๐Ÿ‘‹๐Ÿฝ With re:Invent 2024, AWS finally came up with an answer to what many people (including us) asked for years: "What if there were something like DynamoDB but for SQL?" With Amazon Aurora DSQL, this is finally possible. Itโ€™s not just a โ€œscales-to-zeroโ€ solution like Aurora Serverless V2. It is a true distributed, serverless, pay-per-use...