> Для чего лучше подходят синхронные и асинхронные репликации (Go)

Короткий ответ

Синхронная репликация подходит для систем, где критична консистентность данных и допустима задержка записи: финансовые транзакции, бронирования, системы с жёсткими требованиями к durability. Асинхронная - для высоконагруженных систем с большим объёмом записей, где важнее пропускная способность и низкая латентность, а допустима временная рассинхронизация: аналитика, кэши, логирование, социальные фиды. Выбор - это trade-off между консистентностью и производительностью.

Подробное объяснение

Синхронная репликация гарантирует, что запись подтверждается только после того, как данные записаны на все реплики (или на quorum). Это даёт сильную консистентность: при чтении с любой реплики вы увидите актуальные данные. Но цена - высокая латентность записи (зависит от самой медленной реплики) и снижение пропускной способности. При отказе одной реплики запись может блокироваться или требовать пересмотра quorum.

Асинхронная репликация подтверждает запись сразу после записи на primary, а данные распространяются на реплики в фоне. Это даёт минимальную задержку и высокую пропускную способность. Но возникает окно потери данных при сбое primary до завершения репликации, и возможны чтения устаревших данных с реплик. Также возможна перегрузка primary при большом backlog репликации.

Ключевые факторы выбора:

• требования к RPO (recovery point objective) и RTO (recovery time objective)
• соотношение чтений и записей
• географическая распределённость реплик
• допустимая сложность операций (мониторинг lag, конфликт-резолюция)

В Go-экосистеме это часто реализуется на уровне БД (PostgreSQL synchronous_commit, MongoDB writeConcern) или через паттерны в приложении - например, outbox с асинхронной доставкой событий.

На практике

Для большинства production-систем выбирают гибрид: синхронная репликация для критичных данных (например, для одного-двух узлов в кластере), асинхронная - для остальных. Это даёт баланс между надёжностью и производительностью. В Go важно проектировать сервисы так, чтобы они корректно обрабатывали eventual consistency: использовать идемпотентные операции, versioning, компенсирующие транзакции.

Также стоит учитывать, что синхронная репликация не решает проблему split-brain - нужен консенсус (Raft, etcd) или careful failover. Асинхронная репликация требует мониторинга replication lag и алертов на его превышение.

Пример кода

Пример асинхронной репликации в Go через паттерн outbox:

GO
type Outbox struct {
    mu sync.Mutex
    events []Event
}

func (o *Outbox) Add(e Event) {
    o.mu.Lock()
    defer o.mu.Unlock()
    o.events = append(o.events, e)
}

func (o *Outbox) Flush(ctx context.Context, publish func(Event) error) error {
    o.mu.Lock()
    events := o.events
    o.events = nil
    o.mu.Unlock()

    for _, e := range events {
        if err := publish(e); err != nil {
            // retry with backoff, log, etc.
            return err
        }
    }
    return nil
}

Как отвечать на собеседовании

Начните с чёткого разделения: синхронная - консистентность, асинхронная - производительность. Приведите конкретные примеры систем для каждого типа. Обязательно упомяните trade-off и то, что выбор зависит от бизнес-требований, а не от "лучше/хуже". Покажите понимание последствий: потеря данных, replication lag, влияние на архитектуру. Если спросят про Go - упомяните, что язык не определяет выбор, но влияет на реализацию (goroutines для асинхронной обработки, каналы для очередей). Хорошо, если вы упомянете реальный опыт: как вы выбирали репликацию для конкретной системы и почему.

Что проверяет интервьюер

• понимание фундаментальных trade-off в распределённых системах
• умение связывать технические решения с бизнес-требованиями
• знание конкретных механизмов (quorum, replication lag, durability)
• способность рассуждать о последствиях отказа
• практический опыт (какие проблемы возникали и как решались)

Типичные ошибки

• утверждение, что синхронная репликация "всегда лучше" - это не так, она неприменима для высоконагруженных систем
• игнорирование quorum-механизмов и сценариев частичной доступности
• смешивание репликации с консенсусом (Raft) - это разные вещи
• отсутствие упоминания мониторинга replication lag для асинхронной репликации
• непонимание, что синхронная репликация не гарантирует отсутствие потерь при сетевом разделении без дополнительных механизмов