Forem: XRS0

ClickHouse и работа с ним на Go

XRS0 — Thu, 16 Apr 2026 16:21:59 +0000

1. Вступление: какую проблему решает ClickHouse

ClickHouse нужен там, где обычная OLTP-база начинает мешать аналитике: большие объемы событий, логов, метрик, биллинга, product analytics, ad-tech, observability, отчеты по десяткам миллионов строк и near real-time агрегации. Его сильная сторона — дешево сканировать много данных и быстро выполнять агрегаты, фильтрацию и time-series запросы за счет колоночного хранения, сортировки данных и sparse primary index. При этом производительность в ClickHouse определяется не только SQL, но и физическим дизайном таблицы: ORDER BY, PARTITION BY, стратегия вставки, типы колонок и модель обновления данных. ([ClickHouse][1])

С точки зрения Go-разработчика это важно по двум причинам:

ClickHouse — не “PostgreSQL для аналитики”. Многие привычки из OLTP здесь вредны: частые UPDATE, мелкие INSERT, избыточные JOIN, попытка строить нормализованную модель как в transactional DB. ClickHouse сам рекомендует избегать частых и крупных mutation-операций и проектировать append-only потоки данных там, где это возможно. ([ClickHouse][2])
В Go значительную часть latency и стоимости ingestion вы контролируете сами: batching, transport, context timeout, backpressure, idempotency, retry policy, query settings. Для максимальной производительности официальный clickhouse-go рекомендует native ClickHouse API, а database/sql — скорее для совместимости с инфраструктурой и библиотеками. ([ClickHouse][3])

Типовые кейсы, где связка Go + ClickHouse особенно уместна:

event ingestion из API/gRPC/Kafka consumers;
хранение audit/security событий;
product analytics и clickstream;
observability: traces/logs/metrics;
агрегаты для BI и внутренних дашбордов;
anti-fraud и near real-time scoring по историческим данным.

2. Под капотом: как это устроено

Ключевая модель хранения

В большинстве production-сценариев вы работаете с движками семейства MergeTree. Они:

хранят данные по колонкам;
сортируют данные по ORDER BY;
строят sparse primary index по marks/granules, а не B-Tree по каждой строке;
в фоне сливают data parts внутри partition. ([ClickHouse][4])

Это дает важное следствие:

В ClickHouse primary key — это не про уникальность, а про порядок хранения и сокращение объема сканируемых данных.

ClickHouse прямо указывает, что primary key не обязан быть уникальным, а его выбор влияет и на query performance, и на compression efficiency. ([ClickHouse][5])

`ORDER BY` важнее, чем кажется

ORDER BY определяет физическую сортировку данных в part’ах. Если ваши запросы обычно фильтруют по (tenant_id, event_date, event_type), то именно такой префикс часто дает лучший баланс между pruning и компрессией. Хороший ключ сортировки ускоряет чтение и снижает I/O. ([ClickHouse][5])

`PARTITION BY` — не индекс

Партиционирование нужно для coarse-grained сегментации данных: обычно по месяцу, иногда по дню для observability/time-series. ClickHouse рекомендует не делать слишком гранулярные partition key и в большинстве случаев не использовать partitioning тоньше месяца, кроме сценариев вроде observability, где день — нормальный вариант. Нельзя партиционировать по high-cardinality полям вроде client_id. ([ClickHouse][6])

Вставки: чем крупнее и реже, тем лучше

ClickHouse рекомендует вставлять данные батчами и, для максимальной производительности, использовать Native format. Маленькие частые вставки приводят к разрастанию количества parts и лишней нагрузке на merge-процессы. Если клиентское батчирование неудобно, можно использовать asynchronous inserts: сервер сам буферизует записи и флашит их по порогам. ([ClickHouse][7])

Go-клиенты

Официальная документация выделяет два Go-клиента:

clickhouse-go — high-level клиент, поддерживает native API и database/sql;
ch-go — low-level native-only клиент для максимального контроля и columnar streaming. ([ClickHouse][3])

Практическое правило:

Сценарий	Что брать
Нужен максимальный throughput, batching, нативные фичи ClickHouse	`clickhouse-go` native API
Есть инфраструктурная завязка на `database/sql`	`clickhouse-go` через `OpenDB` / `sql.Open`
Очень горячий ingestion path, columnar streaming, тонкий контроль памяти/CPU	`ch-go`

3. Production-ready примеры

Ниже — реалистичный сценарий: сервис принимает audit events и пишет их в ClickHouse.

3.1. Схема таблицы под audit/event ingestion

CREATE TABLE audit_events
(
    tenant_id       UInt64,
    event_time      DateTime64(3, 'UTC'),
    event_date      Date MATERIALIZED toDate(event_time),
    event_type      LowCardinality(String),
    actor_id        UInt64,
    resource_type   LowCardinality(String),
    resource_id     String,
    request_id      UUID,
    trace_id        String,
    ip              IPv6,
    user_agent      String,
    payload_json    String
)
ENGINE = MergeTree
PARTITION BY toYYYYMM(event_date)
ORDER BY (tenant_id, event_date, event_type, actor_id, event_time, request_id)
TTL event_time + INTERVAL 180 DAY
SETTINGS index_granularity = 8192;

Почему так

PARTITION BY toYYYYMM(event_date) — нормальная гранулярность для большинства event-данных. ClickHouse рекомендует избегать слишком мелкого partitioning. ([ClickHouse][6])
ORDER BY начинается с полей, по которым чаще всего фильтруют: tenant/date/type.
event_type и resource_type как LowCardinality(String) — хороший выбор для повторяющихся строковых значений.
payload_json оставлен строкой: это осознанный компромисс. Не все поля из payload должны становиться отдельными колонками.
TTL позволяет избежать тяжелых ручных удалений для hot storage.

3.2. Подключение из Go через native API

package clickhousex

import (
    "context"
    "crypto/tls"
    "fmt"
    "time"

    clickhouse "github.com/ClickHouse/clickhouse-go/v2"
)

type Config struct {
    Addr     []string
    Database string
    Username string
    Password string
    Secure   bool
}

func NewConn(cfg Config) (clickhouse.Conn, error) {
    opts := &clickhouse.Options{
        Addr: cfg.Addr,
        Auth: clickhouse.Auth{
            Database: cfg.Database,
            Username: cfg.Username,
            Password: cfg.Password,
        },
        DialTimeout: 5 * time.Second,
        MaxOpenConns: 20,
        MaxIdleConns: 10,
        ConnMaxLifetime: 30 * time.Minute,
        Compression: &clickhouse.Compression{
            Method: clickhouse.CompressionLZ4,
        },
        ClientInfo: clickhouse.ClientInfo{
            Products: []struct {
                Name    string
                Version string
            }{
                {Name: "audit-api", Version: "1.0.0"},
            },
        },
    }

    if cfg.Secure {
        opts.TLS = &tls.Config{
            MinVersion: tls.VersionTLS12,
        }
    }

    conn := clickhouse.Open(opts)

    ctx, cancel := context.WithTimeout(context.Background(), 3*time.Second)
    defer cancel()

    if err := conn.Ping(ctx); err != nil {
        return nil, fmt.Errorf("clickhouse ping: %w", err)
    }

    return conn, nil
}

Что здесь важно

Для ClickHouse в Go лучше сразу выставлять DialTimeout, pool limits и compression.
Ping на старте полезен, но не превращайте его в healthcheck на каждый запрос.
Native API предпочтителен по производительности и функциональности; database/sql официально считается более медленным вариантом. ([ClickHouse][3])

3.3. Репозиторий с батчевой вставкой

package repository

import (
    "context"
    "encoding/json"
    "fmt"
    "net"
    "time"

    clickhouse "github.com/ClickHouse/clickhouse-go/v2"
)

type AuditEvent struct {
    TenantID     uint64
    EventTime    time.Time
    EventType    string
    ActorID      uint64
    ResourceType string
    ResourceID   string
    RequestID    string
    TraceID      string
    IP           net.IP
    UserAgent    string
    Payload      map[string]any
}

type AuditRepository struct {
    conn clickhouse.Conn
}

func NewAuditRepository(conn clickhouse.Conn) *AuditRepository {
    return &AuditRepository{conn: conn}
}

func (r *AuditRepository) InsertBatch(ctx context.Context, events []AuditEvent) error {
    if len(events) == 0 {
        return nil
    }

    batch, err := r.conn.PrepareBatch(ctx, `
        INSERT INTO audit_events (
            tenant_id,
            event_time,
            event_type,
            actor_id,
            resource_type,
            resource_id,
            request_id,
            trace_id,
            ip,
            user_agent,
            payload_json
        )
    `)
    if err != nil {
        return fmt.Errorf("prepare batch: %w", err)
    }

    for _, e := range events {
        payloadJSON, err := json.Marshal(e.Payload)
        if err != nil {
            return fmt.Errorf("marshal payload: %w", err)
        }

        if err := batch.Append(
            e.TenantID,
            e.EventTime.UTC(),
            e.EventType,
            e.ActorID,
            e.ResourceType,
            e.ResourceID,
            e.RequestID,
            e.TraceID,
            e.IP,
            e.UserAgent,
            string(payloadJSON),
        ); err != nil {
            return fmt.Errorf("append batch row: %w", err)
        }
    }

    if err := batch.Send(); err != nil {
        return fmt.Errorf("send batch: %w", err)
    }

    return nil
}

Почему это production-grade

батч отправляется одной логической операцией;
сериализация JSON делается один раз на row-level;
ctx пробрасывается в драйвер;
нет string-concatenation SQL;
batching соответствует рекомендациям ClickHouse по insert strategy. ([ClickHouse][8])

3.4. Сервис с буферизацией и flush loop

В реальном API вы редко хотите писать в ClickHouse по одной записи на HTTP request. Обычно нужен буфер.

package ingest

import (
    "context"
    "log"
    "sync"
    "time"

    "example/internal/repository"
)

type AuditWriter struct {
    repo          *repository.AuditRepository
    inputCh       chan repository.AuditEvent
    maxBatchSize  int
    flushInterval time.Duration
    wg            sync.WaitGroup
}

func NewAuditWriter(repo *repository.AuditRepository, maxBatchSize int, flushInterval time.Duration) *AuditWriter {
    return &AuditWriter{
        repo:          repo,
        inputCh:       make(chan repository.AuditEvent, 10000),
        maxBatchSize:  maxBatchSize,
        flushInterval: flushInterval,
    }
}

func (w *AuditWriter) Start(ctx context.Context) {
    w.wg.Add(1)
    go func() {
        defer w.wg.Done()

        ticker := time.NewTicker(w.flushInterval)
        defer ticker.Stop()

        buffer := make([]repository.AuditEvent, 0, w.maxBatchSize)

        flush := func() {
            if len(buffer) == 0 {
                return
            }

            flushCtx, cancel := context.WithTimeout(ctx, 5*time.Second)
            defer cancel()

            if err := w.repo.InsertBatch(flushCtx, buffer); err != nil {
                log.Printf("clickhouse flush failed: %v", err)
                // Здесь можно добавить retry / DLQ / fallback в Kafka.
            }

            buffer = buffer[:0]
        }

        for {
            select {
            case <-ctx.Done():
                flush()
                return

            case ev := <-w.inputCh:
                buffer = append(buffer, ev)
                if len(buffer) >= w.maxBatchSize {
                    flush()
                }

            case <-ticker.C:
                flush()
            }
        }
    }()
}

func (w *AuditWriter) Stop() {
    w.wg.Wait()
}

func (w *AuditWriter) Write(ev repository.AuditEvent) bool {
    select {
    case w.inputCh <- ev:
        return true
    default:
        // Backpressure signal: буфер переполнен.
        return false
    }
}

Архитектурный смысл

Это уже ближе к production ingestion path:

есть bounded buffer;
есть backpressure;
есть controlled flush policy по размеру и времени;
ClickHouse не дергается на каждую запись;
можно встроить retry, DLQ, Kafka fallback, метрики flush_count, flush_latency, flush_errors.

Если у вас много независимых producer’ов и мелкие события, а клиентское batching неудобно, рассмотрите asynchronous inserts на стороне ClickHouse. Это официальный supported path для high-concurrency ingestion. Но тогда важнее мониторить очереди и delayed visibility данных. ([ClickHouse][9])

3.5. Запросы для аналитики

package queries

import (
    "context"
    "fmt"
    "time"

    clickhouse "github.com/ClickHouse/clickhouse-go/v2"
)

type EventAggRow struct {
    EventType string
    Count     uint64
}

func TopEventTypes(
    ctx context.Context,
    conn clickhouse.Conn,
    tenantID uint64,
    from, to time.Time,
    limit uint64,
) ([]EventAggRow, error) {
    query := `
        SELECT
            event_type,
            count() AS cnt
        FROM audit_events
        WHERE tenant_id = ?
          AND event_time >= ?
          AND event_time < ?
        GROUP BY event_type
        ORDER BY cnt DESC
        LIMIT ?
    `

    rows, err := conn.Query(ctx, query, tenantID, from.UTC(), to.UTC(), limit)
    if err != nil {
        return nil, fmt.Errorf("query top event types: %w", err)
    }
    defer rows.Close()

    result := make([]EventAggRow, 0, 32)
    for rows.Next() {
        var row EventAggRow
        if err := rows.Scan(&row.EventType, &row.Count); err != nil {
            return nil, fmt.Errorf("scan row: %w", err)
        }
        result = append(result, row)
    }

    if err := rows.Err(); err != nil {
        return nil, fmt.Errorf("rows err: %w", err)
    }

    return result, nil
}

Best practices для query layer

всегда context.Context;
всегда ограничивайте временной диапазон;
фильтруйте по левому префиксу ORDER BY, если это возможно;
избегайте “wide scan by default” API-методов;
не делайте SELECT * в публичном query path;
декларируйте query contract на уровне репозитория/сервиса.

3.6. Предагрегация через materialized view

Если бизнес постоянно просит “график по часам за 90 дней по tenant/event_type”, не заставляйте ClickHouse считать всё из raw table на каждый запрос. Вынесите это в incremental materialized view: ClickHouse рекомендует materialized views как способ сместить стоимость вычислений на insert time и ускорить SELECT. ([ClickHouse][10])

CREATE TABLE audit_events_hourly
(
    tenant_id    UInt64,
    hour_bucket  DateTime('UTC'),
    event_type   LowCardinality(String),
    total_count  AggregateFunction(sum, UInt64)
)
ENGINE = AggregatingMergeTree
PARTITION BY toYYYYMM(hour_bucket)
ORDER BY (tenant_id, hour_bucket, event_type);

CREATE MATERIALIZED VIEW audit_events_hourly_mv
TO audit_events_hourly
AS
SELECT
    tenant_id,
    toStartOfHour(event_time) AS hour_bucket,
    event_type,
    sumState(toUInt64(1)) AS total_count
FROM audit_events
GROUP BY tenant_id, hour_bucket, event_type;

Чтение:

SELECT
    tenant_id,
    hour_bucket,
    event_type,
    sumMerge(total_count) AS total
FROM audit_events_hourly
WHERE tenant_id = 42
  AND hour_bucket >= now() - INTERVAL 7 DAY
GROUP BY tenant_id, hour_bucket, event_type
ORDER BY hour_bucket;

Когда это оправдано

repeated heavy aggregates;
SLA на latency важнее стоимости insert path;
стабильный набор аналитических срезов;
high-QPS dashboard/read API.

4. Антипаттерны

Антипаттерн 1. Использовать ClickHouse как OLTP-базу

Плохо

писать по одной записи на запрос;
часто делать UPDATE status = ...;
хранить “последнее состояние” как единственную запись;
рассчитывать на row-level transactional semantics как в PostgreSQL.

Почему плохо

ClickHouse оптимизирован под append-heavy аналитические нагрузки. Частые mutations тяжелые и официально не рекомендуются для high-volume таблиц. ([ClickHouse][2])

Лучше

append-only события;
state reconstruction на чтении;
ReplacingMergeTree/CollapsingMergeTree для отдельных кейсов corrections;
TTL и rollups вместо массовых update/delete.

Антипаттерн 2. Партиционировать по high-cardinality ключу

Плохо

PARTITION BY tenant_id

или хуже:

PARTITION BY user_id

Почему плохо

Слишком мелкие partitions ведут к explosion числа parts и ухудшают merge behavior. ClickHouse прямо рекомендует не партиционировать по client identifiers/names. ([ClickHouse][6])

Лучше

PARTITION BY toYYYYMM(event_date)
ORDER BY (tenant_id, event_date, ...)

Антипаттерн 3. Выбирать `ORDER BY` “как получится”

Плохо

ORDER BY (request_id)

если основные запросы — по tenant/date/type.

Почему плохо

Primary key и sort order определяют, сколько данных будет прочитано. Неправильный порядок ломает pruning и компрессию. ([ClickHouse][5])

Лучше

Проектировать ORDER BY от реальных read patterns, а не от формальной уникальности.

Антипаттерн 4. Мелкие inserts из Go без batching

Плохо

for _, ev := range events {
    _, _ = conn.Exec(ctx, "INSERT INTO audit_events ...", ...)
}

Почему плохо

много network round-trips;
рост числа parts;
лишняя нагрузка на merges;
throughput быстро деградирует. ([ClickHouse][8])

Лучше

PrepareBatch и Send;
буфер на приложении;
или async_insert там, где batching на клиенте неудобен. ([ClickHouse][9])

Антипаттерн 5. `database/sql` по умолчанию для hot path

Плохо

Брать database/sql только потому, что “так привычнее”.

Почему плохо

Официальная документация прямо говорит: native ClickHouse API — лучший выбор по производительности и доступу к фичам; database/sql нужен в первую очередь для совместимости. ([ClickHouse][3])

Лучше

ingestion/query-heavy код — native API;
database/sql — только если есть реальная интеграционная причина.

Антипаттерн 6. Хранить всё как `String` или всё как JSON

Плохо

payload String
tenant_id String
actor_id String
event_time String

Почему плохо

Вы теряете компрессию, predicate pushdown, дешевые агрегации и типовую оптимизацию. ClickHouse best practices отдельно акцентируют важность выбора data types. ([ClickHouse][1])

Лучше

типизировать hot-path поля;
JSON оставлять только для редко используемой или вариативной части payload.

5. Хороший и плохой подход: краткое сравнение

Задача	Плохой подход	Хороший подход
Ingestion	`INSERT` по одной записи	batching через `PrepareBatch`, либо async inserts
Модель данных	нормализованная OLTP-схема с частыми update	append-only events + rollups/materialized views
Partitioning	по `tenant_id` / `user_id`	по месяцу или дню для observability
Sorting key	случайный surrogate key	`ORDER BY` от реальных фильтров и диапазонов
Драйвер	`database/sql` “потому что стандарт”	native API для hot path
Агрегации	считать из raw table на каждый запрос	incremental materialized views / pre-aggregation
Удаление старых данных	массовые `DELETE`	TTL policies
Retention	вручную кодом	схема и lifecycle на стороне ClickHouse

6. Trade-offs: когда ClickHouse брать, а когда нет

Плюсы

очень высокая скорость аналитических запросов на больших объемах;
эффективное колоночное хранение и компрессия;
сильный ingestion throughput при правильной стратегии вставки;
удобен для time-series, событий и предагрегаций;
materialized views позволяют переносить вычисления на этап записи. ([ClickHouse][7])

Минусы

не замена OLTP-БД;
schema design критичен: ошибки в ORDER BY и partitioning дорого стоят;
updates/deletes тяжелые;
query model требует дисциплины;
часть команды будет по инерции применять неправильные паттерны из PostgreSQL/MySQL. ([ClickHouse][2])

Когда лучше отказаться

Не стоит выбирать ClickHouse как primary store, если у вас:

transactional workflow с сильной консистентностью и частыми row updates;
много point lookups по PK и почти нет аналитики;
критична OLTP-семантика, foreign keys и rich transactional behavior;
объем данных маленький и PostgreSQL закрывает задачу проще.

Практичное правило:

PostgreSQL — source of truth, transactional state;
ClickHouse — аналитический read store, event lake, observability backend, BI/aggregation layer.

7. TL;DR

ClickHouse в Go — это не просто “еще одна SQL-база”, а отдельная архитектурная модель: append-heavy ingestion + быстрые аналитические чтения.
Производительность определяется прежде всего схемой: ORDER BY, PARTITION BY, типами колонок и insert strategy. ([ClickHouse][1])
Для Go hot path обычно берите clickhouse-go native API, а не database/sql. ([ClickHouse][3])
Делайте batch inserts. Маленькие одиночные вставки — один из самых частых и дорогих антипаттернов. Для high-concurrency workloads рассмотрите asynchronous inserts. ([ClickHouse][8])
Не пытайтесь строить OLTP-паттерны поверх ClickHouse: частые UPDATE/DELETE здесь дорогие. ([ClickHouse][2])
Партиционирование — coarse-grained механизм. Обычно месяц, иногда день для observability. Не partition by tenant/user. ([ClickHouse][6])
Для повторяемых тяжелых агрегатов используйте materialized views и pre-aggregation. ([ClickHouse][10])

2PC vs Saga

XRS0 — Tue, 10 Mar 2026 09:40:11 +0000

Введение: какую проблему вообще решаем

Как только бизнес-операция начинает затрагивать несколько независимых ресурсов, локальная транзакция перестает быть достаточной.

Типичные примеры:

создание заказа требует записи в orders, списания денег через payment-service, резервирования товара в inventory-service;
онбординг клиента требует записи в основную БД, публикации события, создания записи в биллинге и CRM;
операция проходит через несколько микросервисов, у каждого своя БД, собственный жизненный цикл и SLA.

На одном сервисе и одной БД все просто: открыл транзакцию, выполнил BEGIN ... COMMIT, при ошибке сделал ROLLBACK. Но как только появляются несколько источников истины, вопрос становится неприятно взрослым:

Как гарантировать целостность бизнес-операции, если один шаг уже выполнен, а следующий упал?

Здесь обычно и появляется развилка:

2PC (Two-Phase Commit) — попытка добиться атомарности между несколькими участниками;
Saga — попытка управлять распределенной бизнес-операцией через последовательность локальных транзакций и компенсирующих действий.

Это не “два равнозначных паттерна”. Они решают похожую боль, но делают это разными моделями согласованности, с разной ценой по отказоустойчивости, latency, coupling и операционной сложности.

Когда проблема становится архитектурной, а не просто технической

Пока у вас монолит и одна PostgreSQL — не выдумывайте распределенную драму из воздуха. Обычной транзакции достаточно.

Проблема становится архитектурной, когда одновременно верны несколько условий:

Операция пересекает границы сервисов.
Каждый сервис владеет своим состоянием.
Нельзя просто “попробовать еще раз” без учета побочных эффектов.
Частичный успех недопустим или дорого обходится бизнесу.
Нужна управляемая реакция на сбои, а не набор случайных ретраев.

Например:

заказ создан, но деньги не списаны;
деньги списаны, но склад не зарезервировал товар;
склад зарезервировал товар, но email-уведомление не ушло;
платежный провайдер ответил timeout, и вы уже не понимаете: платеж прошел или нет.

Вот здесь выбор между 2PC и Saga начинает влиять не на красоту кода, а на:

SLA операции;
блокировки и конкуренцию;
восстановление после partial failure;
наблюдаемость;
стоимость сопровождения.

1. 2PC: что это и зачем

Идея

Two-Phase Commit — это протокол координации распределенной транзакции между несколькими участниками.

У него есть:

координатор — управляет транзакцией;
участники — ресурсы или сервисы, которые должны либо все зафиксировать изменения, либо все откатить.

Две фазы

Фаза 1: Prepare

Координатор спрашивает всех участников:

Ты можешь зафиксировать изменения?

Каждый участник:

валидирует возможность commit;
фиксирует намерение;
удерживает нужные ресурсы/блокировки;
отвечает YES или NO.

Фаза 2: Commit / Abort

если все ответили YES, координатор рассылает COMMIT;
если хоть один ответил NO, координатор рассылает ROLLBACK.

Ключевая цель 2PC — атомарность между несколькими участниками.

Что 2PC дает архитектурно

2PC полезен там, где бизнес требует именно такого контракта:

либо операция завершена целиком,
либо не завершена вовсе.

Это важно для операций, где компенсация либо невозможна, либо юридически/финансово неэквивалентна откату.

Например:

внутренние финансовые проводки внутри контролируемой инфраструктуры;
несколько таблиц/ресурсов под единым административным контролем;
XA/JTA-подобные enterprise-сценарии, где инфраструктура заранее спроектирована под distributed transaction manager.

Главная проблема 2PC

2PC почти всегда упирается в одно: он плохо дружит с реальностью современных микросервисов.

Почему:

Блокирующая модель
Участники удерживают ресурсы до финального решения координатора. Это ухудшает throughput и увеличивает latency.
Координатор становится критической точкой
Если координатор завис между prepare и commit, участники могут зависнуть в неопределенном состоянии.
Плотная связность
Все участники должны поддерживать совместимый протокол, одинаковую модель транзакционного участия, устойчивое хранение transaction state.
Плохо сочетается с внешними системами
Внешний payment provider, Kafka, email, S3, сторонний REST API — это не участники 2PC в классическом смысле.
Снижение доступности ради согласованности
Если один участник недоступен, вся операция останавливается. Классический CAP-зоопарк машет лапкой.

2. Saga: что это и зачем

Идея

Saga — это последовательность локальных транзакций, где каждая успешно завершившаяся операция при необходимости может быть компенсирована отдельным действием.

Важный момент:

Saga не дает атомарность как 2PC. Она дает управляемую согласованность через eventual consistency и compensation.

Пример цепочки:

orders-service создает заказ со статусом PENDING;
inventory-service резервирует товар;
payment-service списывает деньги;
orders-service переводит заказ в CONFIRMED.

Если шаг 3 упал, выполняются компенсирующие действия:

снять резерв со склада;
перевести заказ в CANCELLED.

Что Saga дает архитектурно

Saga полезна, когда система:

распределенная;
состоит из сервисов с независимыми БД;
взаимодействует с внешними API;
требует высокой доступности;
готова жить с временной несогласованностью.

То есть Saga — это не “обходной путь, потому что 2PC сложно”. Это другая модель работы:

вместо сильной атомарности — управляемый процесс;
вместо глобального rollback — бизнес-компенсация;
вместо блокировок на нескольких ресурсах — локальные commit’ы и асинхронная координация.

Оркестрация и хореография

У Saga две основные формы.

Orchestrated Saga

Есть центральный orchestrator, который знает шаги процесса:

вызвать сервис A;
потом B;
потом C;
при ошибке запустить компенсации в обратном порядке.

Плюсы:

явная логика процесса;
проще трассировать;
лучше для сложных бизнес-флоу.

Минусы:

orchestrator может превратиться в жирного “бога процесса”;
возрастает coupling на workflow-уровне.

Choreographed Saga

Нет центрального координатора. Сервисы публикуют события:

OrderCreated;
InventoryReserved;
PaymentFailed;
OrderCancelled.

Каждый сервис реагирует на события и выполняет свою часть.

Плюсы:

слабее связность;
ближе к event-driven архитектуре.

Минусы:

логика размазывается по системе;
сложнее понять полный workflow;
дебаг превращается в раскопки по логам, если не вложиться в observability.

3. Под капотом: как это устроено технически

2PC под капотом

Минимальная модель такая:

координатор создает transaction_id;
рассылает prepare(transaction_id) всем участникам;
участники записывают durable state: “готов к commit”;
участники удерживают нужные ресурсы;
координатор после сбора ответов пишет свое решение;
рассылает commit или abort;
участники применяют решение и очищают состояние.

Ключевые технические свойства

нужно устойчивое хранение состояния на стороне координатора и участников;
нужно идемпотентное применение commit/abort;
нужно уметь восстанавливаться после падения узла;
нужно решать проблему in-doubt transaction.

Это уже намекает, почему 2PC редко хочется тащить в обычные Go-микросервисы поверх REST и случайного набора внешних API. Это не паттерн уровня “добавим middleware и поехали”. Это инфраструктурный контракт.

Saga под капотом

Для Saga обычно нужны такие элементы:

Идентификатор бизнес-операции
Например, saga_id или workflow_id.
Хранилище состояния процесса
Текущее состояние шагов:

STARTED
INVENTORY_RESERVED
PAYMENT_COMPLETED
FAILED
COMPENSATED

Локальные транзакции
Каждый шаг коммитится локально внутри своего сервиса.
Компенсирующие действия
Не SQL rollback, а осмысленные бизнес-операции:

снять резерв;
инициировать refund;
пометить заказ отмененным.

Идемпотентность
Повтор сообщения или повтор шага не должен ломать состояние.
Retry policy
Нужно различать:

временные ошибки;
постоянные ошибки;
неопределенные ответы (timeout, unknown).

Outbox / Inbox pattern Чтобы не потерять событие между commit в БД и отправкой в брокер.

4. Сравнение 2PC и Saga

Короткая таблица

Критерий	2PC	Saga
Модель согласованности	Сильная атомарность	Eventual consistency
Тип отката	Технический rollback	Бизнес-компенсация
Блокировки	Да, часто есть	Обычно нет глобальных блокировок
Доступность	Ниже	Выше
Latency	Выше	Обычно лучше для распределенной среды
Работа с внешними API	Плохо подходит	Подходит
Операционная сложность	Высокая инфраструктурно	Высокая на уровне workflow
Coupling	Высокий протокольный	Средний/высокий бизнесовый
Восстановление после partial failure	Сложно	Ожидаемая часть модели
Наблюдаемость	Нужна, но сценарий линейнее	Критически важна

5. Production-ready пример: Saga с оркестрацией на Go

Ниже не “идеальный фреймворк”, а приближенная к production схема:

есть order-service;
шаги: создать заказ → зарезервировать товар → списать оплату → подтвердить заказ;
при ошибке: отменить заказ, снять резерв, инициировать refund при необходимости;
состояние workflow хранится в БД;
все внешние вызовы идемпотентны.

Доменные состояния

package saga

import "time"

type SagaStatus string

const (
    SagaStatusStarted      SagaStatus = "STARTED"
    SagaStatusOrderCreated SagaStatus = "ORDER_CREATED"
    SagaStatusReserved     SagaStatus = "INVENTORY_RESERVED"
    SagaStatusPaid         SagaStatus = "PAID"
    SagaStatusCompleted    SagaStatus = "COMPLETED"
    SagaStatusCompensating SagaStatus = "COMPENSATING"
    SagaStatusCompensated  SagaStatus = "COMPENSATED"
    SagaStatusFailed       SagaStatus = "FAILED"
)

type OrderSaga struct {
    ID          string
    OrderID     string
    ProductID   string
    UserID      string
    AmountCents int64
    Status      SagaStatus
    LastError   string
    CreatedAt   time.Time
    UpdatedAt   time.Time
}

Почему так

SagaStatus должен быть явным, а не “угадываться” по косвенным признакам;
LastError нужен для поддержки, retry и ручного восстановления;
Saga.ID — отдельный идентификатор workflow, не путать с OrderID.

Контракты зависимостей

package saga

import "context"

type SagaRepository interface {
    Create(ctx context.Context, saga OrderSaga) error
    UpdateStatus(ctx context.Context, sagaID string, status SagaStatus, lastErr string) error
    Get(ctx context.Context, sagaID string) (OrderSaga, error)
}

type OrderService interface {
    CreatePendingOrder(ctx context.Context, sagaID, userID, productID string, amountCents int64) (string, error)
    ConfirmOrder(ctx context.Context, orderID string) error
    CancelOrder(ctx context.Context, orderID string) error
}

type InventoryService interface {
    Reserve(ctx context.Context, sagaID, productID string) error
    Release(ctx context.Context, sagaID, productID string) error
}

type PaymentService interface {
    Charge(ctx context.Context, sagaID, userID string, amountCents int64) error
    Refund(ctx context.Context, sagaID, userID string, amountCents int64) error
}

Почему интерфейсы такие

у всех методов есть context.Context;
все публичные операции имеют sagaID — это основа идемпотентности и трассировки;
компенсации моделируются как полноправные действия, а не как “ну потом что-нибудь откатим”.

Оркестратор

package saga

import (
    "context"
    "errors"
    "fmt"
    "log/slog"
)

type Orchestrator struct {
    repo      SagaRepository
    orders    OrderService
    inventory InventoryService
    payments  PaymentService
    logger    *slog.Logger
}

func NewOrchestrator(
    repo SagaRepository,
    orders OrderService,
    inventory InventoryService,
    payments PaymentService,
    logger *slog.Logger,
) *Orchestrator {
    return &Orchestrator{
        repo:      repo,
        orders:    orders,
        inventory: inventory,
        payments:  payments,
        logger:    logger,
    }
}

func (o *Orchestrator) Execute(ctx context.Context, s OrderSaga) error {
    if err := o.repo.Create(ctx, s); err != nil {
        return fmt.Errorf("create saga: %w", err)
    }

    orderID, err := o.orders.CreatePendingOrder(ctx, s.ID, s.UserID, s.ProductID, s.AmountCents)
    if err != nil {
        _ = o.repo.UpdateStatus(ctx, s.ID, SagaStatusFailed, err.Error())
        return fmt.Errorf("create pending order: %w", err)
    }
    s.OrderID = orderID

    if err := o.repo.UpdateStatus(ctx, s.ID, SagaStatusOrderCreated, ""); err != nil {
        return fmt.Errorf("update status ORDER_CREATED: %w", err)
    }

    if err := o.inventory.Reserve(ctx, s.ID, s.ProductID); err != nil {
        o.compensate(ctx, s, false)
        return fmt.Errorf("reserve inventory: %w", err)
    }

    if err := o.repo.UpdateStatus(ctx, s.ID, SagaStatusReserved, ""); err != nil {
        o.compensate(ctx, s, false)
        return fmt.Errorf("update status INVENTORY_RESERVED: %w", err)
    }

    if err := o.payments.Charge(ctx, s.ID, s.UserID, s.AmountCents); err != nil {
        o.compensate(ctx, s, false)
        return fmt.Errorf("charge payment: %w", err)
    }

    if err := o.repo.UpdateStatus(ctx, s.ID, SagaStatusPaid, ""); err != nil {
        o.compensate(ctx, s, true)
        return fmt.Errorf("update status PAID: %w", err)
    }

    if err := o.orders.ConfirmOrder(ctx, s.OrderID); err != nil {
        o.compensate(ctx, s, true)
        return fmt.Errorf("confirm order: %w", err)
    }

    if err := o.repo.UpdateStatus(ctx, s.ID, SagaStatusCompleted, ""); err != nil {
        return fmt.Errorf("update status COMPLETED: %w", err)
    }

    o.logger.InfoContext(ctx, "saga completed",
        "saga_id", s.ID,
        "order_id", s.OrderID,
        "product_id", s.ProductID,
    )

    return nil
}

func (o *Orchestrator) compensate(ctx context.Context, s OrderSaga, paymentCaptured bool) {
    if err := o.repo.UpdateStatus(ctx, s.ID, SagaStatusCompensating, "compensation started"); err != nil {
        o.logger.ErrorContext(ctx, "failed to mark saga compensating",
            "saga_id", s.ID,
            "error", err,
        )
    }

    var errs []error

    if paymentCaptured {
        if err := o.payments.Refund(ctx, s.ID, s.UserID, s.AmountCents); err != nil {
            errs = append(errs, fmt.Errorf("refund: %w", err))
        }
    }

    if err := o.inventory.Release(ctx, s.ID, s.ProductID); err != nil {
        errs = append(errs, fmt.Errorf("release inventory: %w", err))
    }

    if s.OrderID != "" {
        if err := o.orders.CancelOrder(ctx, s.OrderID); err != nil {
            errs = append(errs, fmt.Errorf("cancel order: %w", err))
        }
    }

    if len(errs) > 0 {
        joined := errors.Join(errs...)
        _ = o.repo.UpdateStatus(ctx, s.ID, SagaStatusFailed, joined.Error())
        o.logger.ErrorContext(ctx, "saga compensation failed",
            "saga_id", s.ID,
            "error", joined,
        )
        return
    }

    _ = o.repo.UpdateStatus(ctx, s.ID, SagaStatusCompensated, "")
    o.logger.WarnContext(ctx, "saga compensated", "saga_id", s.ID)
}

Что в этом примере правильно

1. Есть явное состояние workflow

Без этого вы не сможете:

безопасно ретраить;
понимать, где упало;
восстанавливаться после рестарта.

2. Компенсация зависит от реально пройденных шагов

Компенсация не должна вслепую дергать все подряд. Например, Refund нужно делать только если платеж действительно прошел.

3. Вызовы должны быть идемпотентными

Reserve, Charge, Refund, Release, CancelOrder обязаны корректно переживать повтор.

Иначе любой retry превратит систему в фабрику дублей.

4. Ошибки компенсации не скрываются

Самая опасная ложь в distributed systems — “ну откатили, наверное”. Нет. Если компенсация не завершилась, это отдельный инцидент.

Как сделать идемпотентность на стороне сервиса

Например, в payment-service:

package payment

import (
    "context"
    "errors"
    "fmt"
)

var ErrAlreadyProcessed = errors.New("already processed")

type Repository interface {
    IsChargeProcessed(ctx context.Context, sagaID string) (bool, error)
    MarkChargeProcessed(ctx context.Context, sagaID string) error
    CreatePayment(ctx context.Context, sagaID, userID string, amountCents int64) error
}

type Service struct {
    repo Repository
}

func (s *Service) Charge(ctx context.Context, sagaID, userID string, amountCents int64) error {
    processed, err := s.repo.IsChargeProcessed(ctx, sagaID)
    if err != nil {
        return fmt.Errorf("check idempotency: %w", err)
    }

    if processed {
        return nil
    }

    if err := s.repo.CreatePayment(ctx, sagaID, userID, amountCents); err != nil {
        return fmt.Errorf("create payment: %w", err)
    }

    if err := s.repo.MarkChargeProcessed(ctx, sagaID); err != nil {
        return fmt.Errorf("mark processed: %w", err)
    }

    return nil
}

В production лучше еще жестче

Обычная проверка “сначала SELECT, потом INSERT” может гоняться в race condition. Надежнее:

уникальный индекс на saga_id или idempotency_key;
INSERT ... ON CONFLICT DO NOTHING;
детерминированное чтение существующего результата.

HTTP-интеграция с idempotency key

package client

import (
    "bytes"
    "context"
    "encoding/json"
    "fmt"
    "net/http"
    "time"
)

type PaymentClient struct {
    baseURL string
    client  *http.Client
}

func NewPaymentClient(baseURL string) *PaymentClient {
    return &PaymentClient{
        baseURL: baseURL,
        client: &http.Client{
            Timeout: 3 * time.Second,
        },
    }
}

type ChargeRequest struct {
    SagaID      string `json:"saga_id"`
    UserID      string `json:"user_id"`
    AmountCents int64  `json:"amount_cents"`
}

func (c *PaymentClient) Charge(ctx context.Context, sagaID, userID string, amountCents int64) error {
    reqBody := ChargeRequest{
        SagaID:      sagaID,
        UserID:      userID,
        AmountCents: amountCents,
    }

    payload, err := json.Marshal(reqBody)
    if err != nil {
        return fmt.Errorf("marshal request: %w", err)
    }

    req, err := http.NewRequestWithContext(ctx, http.MethodPost, c.baseURL+"/payments/charge", bytes.NewReader(payload))
    if err != nil {
        return fmt.Errorf("build request: %w", err)
    }

    req.Header.Set("Content-Type", "application/json")
    req.Header.Set("Idempotency-Key", sagaID)

    resp, err := c.client.Do(req)
    if err != nil {
        return fmt.Errorf("do request: %w", err)
    }
    defer resp.Body.Close()

    switch resp.StatusCode {
    case http.StatusOK, http.StatusCreated, http.StatusConflict:
        // 409 может означать, что операция уже была обработана этим ключом.
        return nil
    default:
        return fmt.Errorf("unexpected payment status: %d", resp.StatusCode)
    }
}

Что важно

timeout обязателен;
Idempotency-Key обязателен;
409 Conflict может быть не ошибкой, а сигналом “эта операция уже была применена”.

6. Outbox pattern: почему без него Saga часто дырявая

Классическая проблема:

вы сделали COMMIT в БД;
потом отправили событие в Kafka/RabbitMQ;
приложение упало между этими шагами.

Результат: состояние в БД изменилось, а событие не ушло. Получается архитектурный шашлык.

Правильнее так

в одной локальной транзакции:
- меняете бизнес-сущность;
- пишете запись в outbox;
отдельный publisher читает outbox и публикует событие;
после успешной публикации помечает запись отправленной.

Схема таблицы

CREATE TABLE outbox_events (
    id UUID PRIMARY KEY,
    aggregate_id TEXT NOT NULL,
    event_type TEXT NOT NULL,
    payload JSONB NOT NULL,
    created_at TIMESTAMPTZ NOT NULL DEFAULT now(),
    published_at TIMESTAMPTZ NULL
);

Пример записи в outbox на Go

package outbox

import (
    "context"
    "database/sql"
    "encoding/json"
    "fmt"

    "github.com/google/uuid"
)

type Event struct {
    AggregateID string
    EventType   string
    Payload     any
}

func SaveOrderCreatedTx(ctx context.Context, tx *sql.Tx, orderID string, payload any) error {
    rawPayload, err := json.Marshal(payload)
    if err != nil {
        return fmt.Errorf("marshal payload: %w", err)
    }

    _, err = tx.ExecContext(ctx, `
        INSERT INTO outbox_events (id, aggregate_id, event_type, payload)
        VALUES ($1, $2, $3, $4)
    `,
        uuid.NewString(),
        orderID,
        "OrderCreated",
        rawPayload,
    )
    if err != nil {
        return fmt.Errorf("insert outbox event: %w", err)
    }

    return nil
}

7. Production-ready пример: локальная транзакция + outbox

package order

import (
    "context"
    "database/sql"
    "fmt"
)

type Repository struct {
    db *sql.DB
}

func (r *Repository) CreatePendingOrder(ctx context.Context, sagaID, userID, productID string, amountCents int64) (string, error) {
    tx, err := r.db.BeginTx(ctx, nil)
    if err != nil {
        return "", fmt.Errorf("begin tx: %w", err)
    }
    defer tx.Rollback()

    var orderID string
    err = tx.QueryRowContext(ctx, `
        INSERT INTO orders (saga_id, user_id, product_id, amount_cents, status)
        VALUES ($1, $2, $3, $4, 'PENDING')
        RETURNING id
    `, sagaID, userID, productID, amountCents).Scan(&orderID)
    if err != nil {
        return "", fmt.Errorf("insert order: %w", err)
    }

    eventPayload := map[string]any{
        "order_id":     orderID,
        "saga_id":      sagaID,
        "user_id":      userID,
        "product_id":   productID,
        "amount_cents": amountCents,
        "status":       "PENDING",
    }

    if err := saveOutboxEvent(ctx, tx, orderID, "OrderCreated", eventPayload); err != nil {
        return "", fmt.Errorf("save outbox: %w", err)
    }

    if err := tx.Commit(); err != nil {
        return "", fmt.Errorf("commit tx: %w", err)
    }

    return orderID, nil
}

Почему это production-friendly

заказ и событие создаются в одной локальной транзакции;
нет окна, где заказ уже есть, а событие потеряно;
это стандартный фундамент для Saga/event-driven процессов.

8. Как выглядел бы 2PC в реальной системе

Честный ответ: в типичном Go-стеке поверх REST/gRPC и независимых микросервисов — скорее всего, никак или очень болезненно.

2PC хорошо работает там, где:

участники умеют входить в distributed transaction protocol;
есть transaction manager;
инфраструктура изначально строилась вокруг этого;
система терпит блокировки и снижение доступности ради строгой атомарности.

В обычной микросервисной архитектуре с:

PostgreSQL у каждого сервиса,
Kafka,
внешним payment gateway,
REST/gRPC между сервисами,

2PC почти всегда либо:

недоступен технически,
либо настолько дорог по coupling и ops cost, что архитектурно проигрывает Saga.

9. Антипаттерны: как не надо делать

Антипаттерн 1. “Сделаем распределенную транзакцию руками через `defer rollbackEverything()`”

func ProcessOrder(ctx context.Context) error {
    if err := createOrder(ctx); err != nil {
        return err
    }
    if err := reserveInventory(ctx); err != nil {
        _ = deleteOrder(ctx)
        return err
    }
    if err := chargePayment(ctx); err != nil {
        _ = releaseInventory(ctx)
        _ = deleteOrder(ctx)
        return err
    }
    return nil
}

Что здесь плохо

нет durable state процесса;
после падения приложения вы не знаете, на каком шаге остановились;
нет идемпотентности;
нет retry policy;
deleteOrder может быть уже невозможен или семантически неверен;
нет observability.

Как рефакторить

ввести saga_id;
хранить состояние шагов;
вынести компенсации в отдельные операции;
сделать шаги идемпотентными;
добавить structured logging и metrics.

Антипаттерн 2. Считать компенсацию эквивалентом rollback

Это очень частая ошибка среднего уровня.

Rollback и compensation — не одно и то же.

Пример:

платеж уже отправлен внешнему провайдеру;
“откатить” это нельзя;
можно только выполнить новую бизнес-операцию — refund.

А refund:

может не пройти;
может пройти с задержкой;
может требовать отдельного согласования;
может иметь комиссии;
может иметь юридические ограничения.

Практический вывод

Если домен не допускает корректной компенсации, Saga может быть плохим выбором.

Антипаттерн 3. Использовать Saga там, где достаточно локальной транзакции

Это классическая микросервисная религиозность.

Если операция живет в:

одном сервисе;
одной БД;
одном bounded context,

то использовать Saga — архитектурное позерство с дополнительными отказами. Не надо строить оркестратор ради изменения двух таблиц в PostgreSQL. Обычный BEGIN/COMMIT умнее и дешевле.

Антипаттерн 4. Не разделять retryable и non-retryable ошибки

Плохой подход:

for i := 0; i < 10; i++ {
    if err := paymentClient.Charge(ctx, sagaID, userID, amount); err == nil {
        return nil
    }
}

Это опасно, потому что:

timeout и validation error — не одно и то же;
429, 502, context deadline exceeded можно ретраить;
400, 403, insufficient_funds — нельзя ретраить бесконечно.

Правильнее

Классифицировать ошибки:

type RetryableError struct {
    Err error
}

func (e RetryableError) Error() string { return e.Err.Error() }

func IsRetryable(err error) bool {
    var re RetryableError
    return errors.As(err, &re)
}

И уже на уровне workflow понимать:

ретрай шага;
переход в компенсацию;
перевод в manual review.

Антипаттерн 5. Нет идемпотентности, но есть брокер сообщений

Если consumer может получить сообщение повторно, а вы это игнорируете, значит вы не “возможно когда-нибудь” словите баг. Вы уже его словили, просто не знаете дату.

Минимум, который нужен

message_id / event_id;
таблица обработанных сообщений;
уникальный индекс;
атомарная фиксация “обработано” вместе с побочным эффектом, где это возможно.

Антипаттерн 6. Хореография без централизованной наблюдаемости

Event-driven workflow без:

correlation ID,
distributed tracing,
нормальных логов,
явных доменных статусов

очень быстро превращается в археологию отказов.

Нужны как минимум

saga_id во всех логах;
trace_id/span_id;
бизнес-метрики:
- количество completed;
- количество compensated;
- среднее время шага;
- количество stuck workflow;
dead-letter queue или аналогичный механизм.

10. Best Practices

Для 2PC

Используйте только если:

инфраструктура реально поддерживает distributed transaction protocol;
участники под вашим контролем;
операция требует сильной атомарности;
вы понимаете стоимость блокировок и coordinator failure.

Не используйте если:

есть внешние API;
сервисы независимы организационно;
нужна высокая доступность;
вы строите event-driven микросервисы.

Для Saga

1. Дизайн шагов должен быть бизнес-ориентированным

Шаг — это не “вызов метода”, а законченная локальная бизнес-операция.

Плохо:

UpdateFieldX
SetFlagY

Хорошо:

ReserveInventory
ChargePayment
ConfirmOrder

2. Компенсация должна быть явной и осмысленной

У каждого шага надо заранее ответить:

что значит “отменить” этот шаг;
что делать, если отмена тоже не удалась;
допускается ли ручное вмешательство.

3. Храните состояние workflow отдельно

Нельзя надеяться, что “в логах потом разберемся”.

Нужно durable state:

текущий шаг;
число попыток;
последняя ошибка;
timestamps;
признак компенсации.

4. Все шаги должны быть идемпотентными

Повтор должен быть безопасен. Это не украшение, а базовая механика распределенной системы.

5. Используйте Outbox/Inbox

Иначе между БД и брокером у вас будет щель, в которую улетит консистентность.

6. Разводите технические и бизнес-ошибки

Например:

timeout — техническая, возможен retry;
card_declined — бизнесовая, нужен fail/compensation;
inventory_not_available — бизнесовая;
db connection reset — техническая.

7. Планируйте manual recovery

Некоторые workflow застрянут. Это не баг проекта, это свойство реальности.

Нужны:

admin endpoint / ops tool;
повтор шага;
запуск компенсации;
перевод в terminal state руками.

11. Где что применять

Когда выбирать 2PC

2PC имеет смысл, если у вас:

ограниченное число участников;
единый административный контроль;
совместимая транзакционная инфраструктура;
критична строгая атомарность;
допустима блокирующая координация.

Реалистичные сценарии

enterprise-системы с XA/JTA;
tightly controlled internal systems;
транзакции между компонентами, которые изначально проектировались под coordinated commit.

Но в обычном мире Go-микросервисов это скорее исключение, чем default choice.

Когда выбирать Saga

Saga имеет смысл, если:

сервисы автономны;
у каждого своя БД;
есть внешние API;
допустима eventual consistency;
нужна высокая доступность и управляемость частичных сбоев.

Реалистичные сценарии

e-commerce checkout;
биллинг и подписки;
бронирования;
onboarding across services;
workflow с event bus.

Когда не использовать ни то ни другое

Когда у вас:

один сервис;
одна БД;
один bounded context.

Тогда правильный ответ почти всегда:

локальная транзакция;
outbox при необходимости публикации событий;
не плодить распределенную координацию без причины.

12. Короткий пример плохого и хорошего подхода

Плохой подход

func Checkout(ctx context.Context, req Request) error {
    orderID, err := createOrder(ctx, req)
    if err != nil {
        return err
    }

    if err := reserveInventory(ctx, req.ProductID); err != nil {
        return err
    }

    if err := chargeCard(ctx, req.UserID, req.Amount); err != nil {
        return err
    }

    return confirmOrder(ctx, orderID)
}

Почему плохо

нет компенсации;
нет состояния процесса;
нет идемпотентности;
нет стратегии восстановления;
partial success гарантированно когда-нибудь случится.

Лучше

func (h *Handler) Checkout(ctx context.Context, req Request) error {
    saga := saga.OrderSaga{
        ID:          req.RequestID,
        UserID:      req.UserID,
        ProductID:   req.ProductID,
        AmountCents: req.AmountCents,
        Status:      saga.SagaStatusStarted,
    }

    return h.orchestrator.Execute(ctx, saga)
}

Почему лучше

workflow отделен от transport-слоя;
есть RequestID/SagaID;
можно безопасно наблюдать, ретраить и компенсировать;
handler не знает деталей межсервисной координации.

13. Trade-offs: неприятная правда без архитектурной косметики

2PC: плюсы

сильная атомарность;
понятная модель “все или ничего”;
проще reasoning на уровне бизнес-инвариантов, если инфраструктура уже поддерживает протокол.

2PC: минусы

блокировки и рост latency;
coordinator failure и in-doubt состояния;
высокая связность;
плохая совместимость с внешними системами;
снижение доступности;
тяжело внедрять в heterogeneous stack.

Saga: плюсы

хорошо ложится на микросервисы;
совместима с внешними API и event bus;
выше доступность;
лучше масштабируется организационно;
сбои становятся ожидаемой частью модели, а не катастрофой вне модели.

Saga: минусы

нет глобической атомарности;
нужна сложная логика компенсации;
observability обязательна;
сложнее reasoning: состояние может быть временно несогласованным;
ручное восстановление и ops tooling почти неизбежны.

14. Практическое правило выбора

Вот довольно рабочее правило без архитектурной мистики:

Выбирайте 2PC, если одновременно верны все условия:

нужна именно сильная атомарность;
участники умеют в coordinated commit;
инфраструктура под вашим контролем;
цена блокировок приемлема;
external API не участвуют.

Выбирайте Saga, если:

у вас микросервисы с независимыми БД;
есть внешние вызовы;
eventual consistency приемлема;
вы готовы инвестировать в idempotency, outbox, observability и compensation design.

Выбирайте обычную локальную транзакцию, если:

все изменения происходят внутри одного сервиса и одной БД.

Это, кстати, самый недооцененный вывод. Многие команды лезут в Saga не потому, что она нужна, а потому что слово солидное и пахнет конференцией.

15. TL;DR

Ключевая разница

2PC — про глобальную атомарность через координацию commit между участниками.
Saga — про управляемую распределенную бизнес-операцию через локальные транзакции и компенсации.

Что выбрать в современных Go-сервисах

Для типичной микросервисной системы на Go выбор почти всегда в пользу Saga, а не 2PC, потому что:

сервисы независимы;
внешние системы не умеют участвовать в distributed transaction;
доступность важнее глобической блокирующей согласованности;
eventual consistency обычно приемлема на уровне бизнеса.

Что обязательно для Saga

saga_id / correlation id;
durable state workflow;
идемпотентность всех шагов и компенсаций;
outbox/inbox;
retry policy;
observability;
manual recovery path.

Когда Saga — плохая идея

если компенсация неэквивалентна и домен не терпит временной несогласованности;
если все и так живет в одной БД;
если команда не готова поддерживать workflow-логику и ops-процедуры.

Когда 2PC оправдан

если инфраструктура специально под него построена;
если участники транзакции полностью контролируются;
если строгая атомарность важнее доступности и throughput.

Итог

Выбор между 2PC и Saga — это не вопрос вкуса и не “что моднее”. Это выбор между двумя моделями:

сильная согласованность ценой связности и доступности;
гибкая распределенная координация ценой eventual consistency и сложности компенсаций.

Для большинства production-систем на Go, где есть отдельные сервисы, брокеры, PostgreSQL, gRPC/HTTP и внешние провайдеры, Saga — практический default, а 2PC — специальный инструмент для узкого класса задач.

Самая здравая стратегия обычно такая:

сначала спросить, нельзя ли решить задачу локальной транзакцией;
если нет — проверить, нужна ли действительно глобальная атомарность;
если нет — строить Saga с нормальной идемпотентностью, outbox и наблюдаемостью, а не на честном слове и панике в логах.

Forem: XRS0

ClickHouse и работа с ним на Go

1. Вступление: какую проблему решает ClickHouse

2. Под капотом: как это устроено

Ключевая модель хранения

ORDER BY важнее, чем кажется

PARTITION BY — не индекс

Вставки: чем крупнее и реже, тем лучше

Go-клиенты

3. Production-ready примеры

3.1. Схема таблицы под audit/event ingestion

Почему так

3.2. Подключение из Go через native API

Что здесь важно

3.3. Репозиторий с батчевой вставкой

Почему это production-grade

3.4. Сервис с буферизацией и flush loop

Архитектурный смысл

3.5. Запросы для аналитики

Best practices для query layer

3.6. Предагрегация через materialized view

Когда это оправдано

4. Антипаттерны

Антипаттерн 1. Использовать ClickHouse как OLTP-базу

Антипаттерн 2. Партиционировать по high-cardinality ключу

Антипаттерн 3. Выбирать ORDER BY “как получится”

Антипаттерн 4. Мелкие inserts из Go без batching

Антипаттерн 5. database/sql по умолчанию для hot path

Антипаттерн 6. Хранить всё как String или всё как JSON

5. Хороший и плохой подход: краткое сравнение

6. Trade-offs: когда ClickHouse брать, а когда нет

Плюсы

Минусы

Когда лучше отказаться

7. TL;DR

2PC vs Saga

Введение: какую проблему вообще решаем

Когда проблема становится архитектурной, а не просто технической

1. 2PC: что это и зачем

Идея

Две фазы

Фаза 1: Prepare

Фаза 2: Commit / Abort

Что 2PC дает архитектурно

Главная проблема 2PC

2. Saga: что это и зачем

Идея

Что Saga дает архитектурно

Оркестрация и хореография

Orchestrated Saga

Choreographed Saga

3. Под капотом: как это устроено технически

2PC под капотом

Ключевые технические свойства

Saga под капотом

4. Сравнение 2PC и Saga

Короткая таблица

5. Production-ready пример: Saga с оркестрацией на Go

Доменные состояния

Почему так

Контракты зависимостей

Почему интерфейсы такие

Оркестратор

Что в этом примере правильно

1. Есть явное состояние workflow

2. Компенсация зависит от реально пройденных шагов

3. Вызовы должны быть идемпотентными

4. Ошибки компенсации не скрываются

Как сделать идемпотентность на стороне сервиса

В production лучше еще жестче

HTTP-интеграция с idempotency key

Что важно

6. Outbox pattern: почему без него Saga часто дырявая

Правильнее так

Схема таблицы

Пример записи в outbox на Go

7. Production-ready пример: локальная транзакция + outbox

Почему это production-friendly

8. Как выглядел бы 2PC в реальной системе

9. Антипаттерны: как не надо делать

`ORDER BY` важнее, чем кажется

`PARTITION BY` — не индекс

Антипаттерн 3. Выбирать `ORDER BY` “как получится”

Антипаттерн 5. `database/sql` по умолчанию для hot path

Антипаттерн 6. Хранить всё как `String` или всё как JSON

Антипаттерн 1. “Сделаем распределенную транзакцию руками через `defer rollbackEverything()`”