Why Strong Consistency?
Eventual consistency усложняет разработку и эксплуатацию: в EC2 control plane на MySQL-дереве репликация вызывала costly операции и странное поведение, когда чтения "откатывали время". Даже в современных сервисах вроде Aurora это приводит к ошибкам — после create_resource(id) запрос get_resource_state(id) на read replica может вернуть "ресурс не существует" из-за задержки репликации. Клиенты вынуждены писать retry-циклы с sleep(100), что добавляет latency, нагружает сервер и рискует зациклиться (особенно если ошибка от удаления). Даже wait_for_resource не спасает: второй get может уйти на другую реплику.
Разработчики сервисов страдают от багов в read-modify-write паттернах, как очистка attachments: stale списки приводят к неполной уборке, неудачным удалениям или ложным assert'ам. Нужно роутить такие reads на primary, снижая пользу от реплик. RMW — каноническая транзакционная нагрузка (UPDATE после SELECT), где replica-reads дают неверные значения. AWS инвестировал в strong consistency для всех reads в Aurora DSQL, устраняя эти проблемы.