Если убрать транзакцию и сделать атомарное обновление, второй запрос (запись в соседнюю таблицу) может упасть — как обеспечить консистентность?

Если убрать транзакцию и сделать атомарное обновление, но второй запрос (например, запись в соседнюю таблицу) может упасть, чтобы обеспечить консистентность данных, можно использовать следующие подходы:

1. Идемпотентность и компенсационные операции: если второй запрос упал, запускается компенсирующая операция, которая откатывает первый запрос или исправляет состояние.

2. Использование очередей и событий (Event Sourcing): первый запрос фиксируется, а запись во вторую таблицу делается асинхронно через очередь. Если запись упала, можно повторить попытку без потери данных.

3. Двухфазный коммит (2PC): хотя это сложнее, можно реализовать протокол, который гарантирует согласованность между двумя операциями.

4. Логирование изменений и периодическая синхронизация: фиксировать изменения в журнале и периодически синхронизировать данные между таблицами.

Пример с использованием очереди в Go:

// После успешного обновления первой таблицы отправляем событие в очередь
err := updateFirstTable(data)
if err != nil {
    return err
}

err = sendToQueue(dataForSecondTable)
if err != nil {
    // Логируем ошибку, чтобы повторить позже
}

Таким образом, достигается eventual consistency, а данные не теряются.