What change should be made to avoid causing disruptions in device operations?
Update the backend to use strongly consistent reads. Update the devices to always write to and read from their home AWS Region.
Enable strong consistency globally on a DynamoDB global table. Update the backend to use strongly consistent reads.
Switch the backend data store to Amazon Aurora MySQL with cross-region replicas. Update the backend to always write to the master endpoint.
Select one AWS Region as a master and perform all writes in that AWS Region only. Update the backend to use strongly consistent reads.
Explanations:
Using strongly consistent reads ensures that the most up-to-date data is retrieved. However, forcing devices toalwayswrite to their home region negates the benefit of having a global table for low-latency writes. The problem is stale reads after writes, so ensuring consistent reads is the key and writing to the closest region is still desirable for latency. Therefore, only the read operation needs to be strongly consistent.
Enabling strong consistencygloballyon a DynamoDB global table is not possible. Global tables provide eventual consistency by default. Strongly consistent reads can only be performed within a single region. This option does not address the core issue and is not a valid configuration.
Switching to Aurora with cross-region replicas is a significantly more complex and expensive solution than necessary. The issue is with read consistency, which can be addressed within DynamoDB. Migrating to a completely different database technology is overkill.
Selecting one AWS Region as a master and performing all writes there introduces significant latency for devices far from that region. This defeats the purpose of having a multi-region deployment for low-latency access. It also creates a single point of failure.
I conclude that the answer is:
Update the backend to use strongly consistent reads. Update the devices to always write to and read from their home AWS Region.