Khi ứng dụng phục vụ khách hàng ở nhiều châu lục, dữ liệu cũng cần nằm gần họ và được đồng bộ giữa các Region.

MFTECH mở rộng sang thị trường châu Âu và Hoa Kỳ. Ứng dụng được triển khai tại mỗi Region; vấn đề cần giải quyết là cách tổ chức dữ liệu.

• Global tables: mỗi Region có một replica, mọi replica đều hỗ trợ đọc và ghi. Ở chế độ mặc định (multi-Region eventual consistency, MREC), DynamoDB tự động sao chép bất đồng bộ, thường trong vòng một giây; chế độ multi-Region strong consistency (MRSC) cũng có sẵn khi cần đọc nhất quán mạnh giữa các Region. Ứng dụng sử dụng DynamoDB API như trước. Với tải ổn định, sử dụng Provisioned + Auto Scaling để tối ưu chi phí; lưu ý thao tác ghi trên global table được tính theo replicated write unit (rWCU/rWRU) tại mọi Region có replica.
• Aurora Global Database: một primary Region tiếp nhận ghi, tối đa 10 secondary Region chỉ đọc. Phù hợp khi ứng dụng đã sử dụng SQL và JOIN, chỉ cần đọc với độ trễ thấp tại Region khác. Khi chỉ một bảng cần phạm vi toàn cầu và các bảng khác chỉ cần trong Region: tách riêng bảng đó, không cần chuyển toàn bộ database.

When an application serves customers on several continents, the data must also sit close to them and stay in sync across Regions.

MFTECH expands into the European and US markets. The application is deployed in each Region; the problem to solve is how to organize the data.

• Global tables: each Region has a replica, and every replica supports reads and writes. In the default mode (multi-Region eventual consistency, MREC), DynamoDB replicates asynchronously and automatically, usually within one second; multi-Region strong consistency (MRSC) mode is also available when you need strongly consistent reads across Regions. The application uses the DynamoDB API as before. For steady load, use Provisioned + Auto Scaling to optimize cost; note that writes to a global table are billed as replicated write units (rWCU/rWRU) in every Region that has a replica.
• Aurora Global Database: one primary Region accepts writes, with up to 10 read-only secondary Regions. Suits applications that already use SQL and JOINs and only need low-latency reads in other Regions. When only one table needs global reach and the other tables are needed only within the Region: split that table out; there is no need to move the whole database.