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

Критерии, которые стоит проговорить вслух

Как это связано со связностью

Синхронный вызов даёт временную связность (temporal coupling): чтобы сервис A работал, сервис B должен быть жив прямо в эту миллисекунду. Плюс связность по адресу: A знает, что B существует и как его найти. Событие снимает временную связность полностью - потребитель может лежать час, события подождут в топике. Но взамен приходит связность по схеме: все потребители завязаны на формат события, и его изменение задевает всех сразу. Поэтому формулировка «асинхронно = развязано» неполная: связность не исчезает, она переезжает из времени в контракт.

Гибриды, которые полезно назвать

• Синхронно для чтения, асинхронно для записи. Заказ создаётся синхронно (клиенту нужен номер), а бонусы, кэшбэк и письмо уходят событиями.
• Локальный кэш чужих данных. Вместо синхронного вызова «дай мне тариф» подписываемся на события изменения тарифов и держим локальную копию. Убирает хоп и временную связность ценой окна устаревания. Это event-carried state transfer.
• Асинхронный запрос-ответ (очередь запросов + очередь ответов + correlation id): нужен, когда операция длинная (генерация отчёта, конвертация видео), а клиент опрашивает статус или получает вебхук.

Event notification

Событие содержит минимум: тип, идентификатор сущности, время, версию. Потребитель, которому нужны подробности, делает синхронный вызов обратно к владельцу.

// notification: только факт и ссылка
type OrderPaid struct {
    EventID    string    `json:"event_id"`   // для дедупликации
    OrderID    string    `json:"order_id"`
    OccurredAt time.Time `json:"occurred_at"`
    Version    int       `json:"version"`    // версия агрегата, не схемы
}

• Плюс: событие крошечное, схема почти не меняется, нет дублирования данных, нет вопроса «а что если в событии устаревшие данные».
• Минус: временная связность вернулась через заднюю дверь - потребитель обязан сходить к продюсеру, и если тот лежит, обработка встала. Плюс N потребителей дают N обратных запросов на каждое событие (эффект «громового стада» по владельцу).
• Ещё минус: гонка. Событие «заказ оплачен» пришло, потребитель пошёл читать заказ и увидел уже отменённый заказ - состояние ушло вперёд относительно события. Лечится так: в событии едет версия, а потребитель проверяет, не старее ли то, что он прочитал.

Event-carried state transfer

Событие несёт всё, что нужно типичному потребителю, и потребитель строит у себя локальную денормализованную копию.

type OrderPaid struct {
    EventID    string      `json:"event_id"`
    OrderID    string      `json:"order_id"`
    UserID     string      `json:"user_id"`
    Amount     Money       `json:"amount"`
    Items      []OrderItem `json:"items"`
    Address    Address     `json:"address"`
    OccurredAt time.Time   `json:"occurred_at"`
    Version    int         `json:"version"`
}

• Плюс: полная временная развязка - потребитель работает, даже если владелец лежит сутки. Нет обратного трафика. Потребитель может отвечать на свои запросы из своей копии, и его латентность не зависит от чужой.
• Минус: событие большое, схема меняется чаще, данные продублированы в N местах, и любое изменение смысла поля надо согласовывать со всеми потребителями.
• Минус, о котором забывают: в каждой локальной копии свой лаг, и наружу пользователь видит расхождение между экранами. Нужен способ пересобрать копию с нуля (replay топика или отдельный «полный снимок»).

Audit log - и чем он не является

Audit log хранит журнал того, что произошло, для людей и регуляторов: кто, когда, что изменил, с какого IP, по какому запросу. Его пишут рядом с основным состоянием, и нужен он для расследований, комплаенса, разбора инцидентов.

Его постоянно путают с event sourcing, и разница принципиальная: в event sourcing истина лежит в событиях, а состояние выводится из них; в audit log истину хранит состояние, а журнал вторичен. Если удалить audit log, система продолжит работать корректно и никто не потеряет данные - пропадёт только история. Если удалить события в event sourcing, система перестанет существовать. Отсюда практическое следствие: audit log вводится дёшево и почти всегда окупается (отдельная таблица, отдельный топик, запись через триггер или в той же транзакции), а event sourcing остаётся тяжёлым архитектурным решением, которое меняет всё.

Что даёт локальная транзакция и что из этого исчезает

• Атомарность держится на WAL: до COMMIT ничего не видно, после видно сразу всё. Между сервисами общего журнала нет: сервис A уже закоммитил, сервис B вернул ошибку, и никто уже не «развидит» коммит A.
• Изоляция держится на блокировках и снимках внутри одного движка. Через сеть изоляция означала бы держать блокировку в чужой БД на время сетевого раунд-трипа, а это убивает пропускную способность и делает систему заложником чужой латентности.
• Долговечность у каждого своя, и они не синхронизированы: A мог сфсинкать на диск, а B в этот момент потерял питание до fsync.

Три конкретные причины, которые звучат убедительно

1. Неотличимость отказа от задержки. Ты послал «коммить» и не получил ответ. Он не дошёл? Дошёл, но ответ потерялся? Узел жив и коммитит прямо сейчас? С точки зрения отправителя эти три случая идентичны, а действий требуют противоположных. Это не инженерная недоработка, а свойство асинхронной сети.
2. Блокировки через сеть. Любой протокол атомарного коммита обязан держать ресурсы «замороженными» до общего решения. Время заморозки = сетевая задержка + время на согласование, то есть в тысячи раз больше локального коммита. Пропускная способность падает на порядок, а горячие строки становятся глобальным узким местом.
3. Автономность сервисов. Микросервисы вводились именно ради того, чтобы команда владела своей схемой и релизила независимо. Общая транзакция возвращает общую блокировочную судьбу: деплой одного сервиса вешает транзакции другого. Технически это ещё и требует, чтобы у всех участников был XA-совместимый ресурс - а у Kafka, Redis, S3 и большинства внешних API его нет в принципе.

Что делают вместо

• Переопределить границу. С этого и стоит начинать: если две операции обязаны быть атомарными по бизнесу, скорее всего они принадлежат одному bounded context и не должны быть в разных сервисах. Списание с баланса и запись в историю баланса живут в одном сервисе, в одной БД, в одной транзакции.
• Сага выстраивает цепочку локальных транзакций с компенсациями и меняет изоляцию на доступность.
• Transactional outbox запирает «изменил состояние + отправил сообщение» в одну локальную транзакцию, дальше идёт at-least-once доставка.
• Идемпотентность + повтор до успеха. Если операция идемпотентна, «не знаю, прошло ли» лечится повтором, и половина проблемы исчезает.
• Сверка. Фоновый процесс, который сравнивает состояния двух сервисов и чинит расхождения. В финтехе это обязательный элемент, а не костыль: любая распределённая система рано или поздно расходится, и вопрос только в том, заметишь ты это сам или тебе скажет клиент.

Сравнение по существу

Сильный ответ добавляет границу: оркестратор допустим, пока он координирует, а не решает. Как только в него переезжают бизнес-правила участников («если сумма больше 100 000, то проверить лимит и позвать риск-скоринг»), сервисы становятся анемичными CRUD-обёртками, и получается распределённый монолит с единой точкой изменений. Признак болезни: каждая новая фича в любом сервисе требует правки оркестратора.

Компенсации: правила, которые отличают знающего

1. Компенсация не откатывает, а делает обратную бизнес-операцию. «Отменить бронь», «сделать возврат», «послать письмо об отмене». Обе операции остаются в истории.
2. Необратимые шаги ставь в конец. Отправка письма, выдача физического товара, списание во внешней системе без возврата. Всё, что можно откатить, идёт раньше.
3. Компенсации идемпотентны и ретраебельны без ограничения по числу попыток - система уже в промежуточном состоянии, «сдаться» нельзя. Ключ идемпотентности складывается из saga_id + step.
4. Компенсация не должна уметь отказать по бизнес-причине. Если может - порядок шагов выбран неверно.
5. Семантические блокировки вместо изоляции. Статус RESERVED с TTL вместо реального удержания строки. Наружу промежуточное состояние показывается как «в обработке», а не как результат.

Персистентное состояние - обязательное, не опциональное

Оркестратор без таблицы саг не переживает рестарт пода. Схема, конечный автомат и код перехода приведены в теории выше; на собесе достаточно назвать четыре свойства: состояние в БД, один воркер на сагу (SELECT ... FOR UPDATE или партиционирование по saga_id), таймаут у каждого ожидающего состояния (next_retry_at + фоновый сканер зависших), терминальные состояния, включая NEEDS_ATTENTION для ручного разбора.

2PC позволяет нескольким независимым базам закоммитить одну общую транзакцию по принципу «либо все, либо никто». Работает это как сделка через нотариуса. Сначала нотариус обходит участников и спрашивает каждого: «ты готов подписать?». Тот, кто ответил «да», уже не может передумать и обязан ждать. Когда «да» сказали все, нотариус объявляет «подписываем» - и только в этот момент сделка состоялась. Нотариус здесь называется координатором, остальные участниками, а два обхода и есть две фазы.

Аналогия ломается ровно в одном месте: нотариус может выйти из комнаты между вопросом и объявлением. Участники, уже сказавшие «да», останутся сидеть связанными - отказаться нельзя, подписать без объявления нельзя, разойтись нельзя. Именно это и называют блокирующим окном.

Как работает

1. Фаза 1, prepare. Координатор рассылает PREPARE. Каждый участник выполняет работу, записывает всё необходимое в свой журнал, берёт блокировки и отвечает YES (обещание: «я гарантированно смогу закоммитить, что бы дальше ни случилось») или NO. После YES участник теряет право решать самостоятельно - он в неопределённости.
2. Фаза 2, commit/abort. Если все ответили YES, координатор пишет решение COMMIT в свой журнал (эта запись и есть точка невозврата) и рассылает её. Иначе рассылает ABORT. Участники применяют решение и отпускают блокировки.

Почему избегают: пять причин по убыванию важности

1. Блокирующий протокол. Доказано, что атомарный коммит без блокировки при отказе координатора невозможен в асинхронной сети. Падение координатора в окне между фазами замораживает данные у всех участников. Восстановиться можно только по журналу координатора - то есть координатор становится критической единой точкой отказа, которую надо реплицировать (и тогда ты уже строишь консенсус).
2. Доступность перемножается и падает. Транзакция успешна, только если живы все участники плюс координатор. Четыре компонента по 99.9 % дают 99.6 %.
3. Латентность и пропускная способность. Два сетевых раунда плюс fsync журнала у каждого; блокировки держатся всё это время. Горячая строка (баланс, склад) превращается в глобальный сериализатор.
4. Не все ресурсы поддерживают XA. Kafka, Redis, S3, внешние платёжные API - фазы prepare у них нет. Двухфазный коммит работает только в мире «несколько реляционных БД под одним менеджером транзакций», а это ровно та монолитная картина, от которой уходили.
5. Связывает автономию. Общая транзакция означает общие релизы, общие окна обслуживания и общий инцидент.

Проблема dual write

// Так нельзя: два разных хранилища, атомарности нет
func (s *Service) PayOrder(ctx context.Context, id string) error {
    if err := s.db.MarkPaid(ctx, id); err != nil {   // (1)
        return err
    }
    return s.broker.Publish(ctx, OrderPaid{OrderID: id}) // (2)
}

Между (1) и (2) четыре разных плохих исхода. Процесс упал после коммита - событие потеряно навсегда, а данные изменены. Брокер недоступен, и результат тот же. Publish прошёл, но ответ не дошёл и мы вернули ошибку: клиент повторит, событие уедет дважды. Publish поставили перед коммитом, событие ушло, а транзакция откатилась; сообщение о том, чего не было, чинить уже нечем, и это худший из вариантов. Ретраи внутри функции не спасают: нет способа откатить уже опубликованное сообщение.

Outbox: реализация

CREATE TABLE outbox (
    id             bigserial PRIMARY KEY,      -- монотонность = порядок публикации
    aggregate_type text        NOT NULL,       -- 'order'
    aggregate_id   text        NOT NULL,       -- ключ партиционирования в брокере
    event_type     text        NOT NULL,       -- 'order.paid.v1'
    payload        jsonb       NOT NULL,
    headers        jsonb       NOT NULL DEFAULT '{}',   -- trace_id, correlation_id
    created_at     timestamptz NOT NULL DEFAULT now(),
    published_at   timestamptz                 -- NULL = ещё не отправлено
);
CREATE INDEX outbox_unpublished ON outbox (id) WHERE published_at IS NULL;

func (s *Service) PayOrder(ctx context.Context, id string) error {
    return s.db.InTx(ctx, func(tx *sql.Tx) error {
        if err := markPaid(tx, id); err != nil {  // бизнес-изменение
            return err
        }
        return insertOutbox(tx, Event{           // сообщение в той же транзакции
            AggregateID: id,
            Type:        "order.paid.v1",
            Payload:     mustJSON(OrderPaid{OrderID: id}),
        })
    })
}

// Отдельный релей: читает пачками, публикует, помечает.
func (r *Relay) tick(ctx context.Context) error {
    rows := r.db.Query(ctx, `SELECT id, aggregate_id, event_type, payload
                             FROM outbox WHERE published_at IS NULL
                             ORDER BY id LIMIT 200
                             FOR UPDATE SKIP LOCKED`)   // несколько релеев не мешают друг другу
    for _, e := range rows {
        if err := r.broker.Publish(ctx, e.Key(), e.Payload); err != nil {
            return err                                   // не помечаем, повторим
        }
        r.db.Exec(ctx, `UPDATE outbox SET published_at = now() WHERE id = $1`, e.ID)
    }
    return nil
}

Вычитывать outbox можно двумя способами. Polling publisher работает как в коде выше: просто, заводится с любой БД, а платишь задержкой на интервал опроса и лишней нагрузкой на БД. CDC / log tailing читает WAL напрямую (Debezium + Postgres logical replication): нулевая нагрузка на таблицы, минимальная задержка, честный порядок, но плюс один серьёзный компонент в инфраструктуре и своя эксплуатация.

Inbox: зеркало на стороне потребителя

CREATE TABLE inbox (
    message_id   text PRIMARY KEY,             -- event_id продюсера
    consumer     text        NOT NULL,
    processed_at timestamptz NOT NULL DEFAULT now()
);

func (c *Consumer) Handle(ctx context.Context, m Message) error {
    return c.db.InTx(ctx, func(tx *sql.Tx) error {
        ok, err := claim(tx, m.ID, c.name)  // INSERT ... ON CONFLICT DO NOTHING
        if err != nil {
            return err
        }
        if !ok {
            return nil                      // уже обрабатывали, тихо подтверждаем
        }
        return c.apply(tx, m)               // эффект и отметка в одной транзакции
    })
}

Отметка об обработке и сам эффект должны лежать в одной локальной транзакции. Если пометить в Redis, а изменение сделать в Postgres, вернулся тот же dual write, только на стороне потребителя. Inbox нужен не всегда: если сам эффект естественно идемпотентен (UPSERT по ключу, SET статуса, «положить файл по имени»), отдельная таблица избыточна.

Подводные камни, которые стоит назвать самому

• Порядок. Публикация по ORDER BY id плюс ключ партиционирования = aggregate_id сохраняет порядок в пределах агрегата. С параллельными релеями и SKIP LOCKED глобального порядка нет - и он обычно не нужен, но это надо сказать вслух.
• Раздувание таблицы. Outbox становится самой горячей таблицей на запись. Нужен DELETE/партиционирование по дням с отрезанием старых партиций, иначе автовакуум и индексы деградируют.
• Разрыв «изменил - забыл записать в outbox». Лечится тем, что публикацию прячут в репозиторий/UoW, а не оставляют на дисциплину разработчика.
• Транзакция стала длиннее на одну вставку - обычно незаметно, но на очень горячих путях это лишний WAL-трафик, и его надо учитывать.
• Не путать с Kafka transactions. Транзакции Kafka дают атомарность «прочитал из топика - записал в топик» внутри Kafka, но не связывают Kafka с твоей БД. Мост «БД ↔ брокер» всё равно строится через outbox или CDC.

CQRS по уровням, от дешёвого к дорогому

1. Разные модели в коде. CreateOrderCommand и OrderListItem устроены по-разному, потому что у записи и чтения разные инварианты. Стоит почти ничего, полезно почти всегда.
2. Разные пути доступа. Запись через доменную модель с валидацией и агрегатами, чтение - прямым SQL с джойнами в плоский DTO, минуя домен. Убирает половину «мапперов ради мапперов».
3. Реплика для чтения. Та же схема, но чтение с read-replica. Появляется репликационный лаг и вопрос read-your-writes.
4. Отдельное хранилище для чтения. Проекция в Elasticsearch/Redis/денормализованную таблицу, обновляемая событиями. Настоящая цена начинается тут: eventual consistency, пересборка проекций, мониторинг лага, обработка «проекция сломалась».

Оправдан, когда профили чтения и записи разошлись объективно: соотношение чтений к записям 100:1 и больше; чтения требуют агрегатов и полнотекстового поиска, которые ломают нормализованную схему записи; масштабировать надо только одну сторону; разным потребителям нужны принципиально разные представления одних данных. Не оправдан на CRUD с равномерной нагрузкой - там он просто удваивает код и добавляет окно рассинхрона на ровном месте.

Event sourcing: механика

Источником истины служит append-only лог событий агрегата. Текущее состояние получается свёрткой: state = fold(apply, events). Запись добавляет событие и проверяет оптимистичную блокировку по номеру версии.

// Событие неизменяемо и в прошедшем времени: оно уже случилось.
type Event interface{ isEvent() }

type AccountOpened struct {
    ID, Owner string
}
type Deposited struct {
    Amount Money
}
type Withdrawn struct {
    Amount Money
}

// метод-маркер: запечатывает интерфейс, чужой тип событием не притворится
func (AccountOpened) isEvent() {}
func (Deposited) isEvent()     {}
func (Withdrawn) isEvent()     {}

type Account struct {
    ID      string
    Balance Money
    Version int
}

func (a *Account) Apply(e Event) {          // чистая функция без побочных эффектов
    switch v := e.(type) {
    case AccountOpened:
        a.ID = v.ID
    case Deposited:
        a.Balance = a.Balance.Add(v.Amount)
    case Withdrawn:
        a.Balance = a.Balance.Sub(v.Amount)
    }
    a.Version++
}

// Команда: загрузили состояние, проверили инвариант, вернули новые события.
func (a *Account) Withdraw(amount Money) ([]Event, error) {
    if a.Balance.Less(amount) {
        return nil, ErrInsufficientFunds
    }
    return []Event{Withdrawn{Amount: amount}}, nil
}

CREATE TABLE events (
    stream_id  text     NOT NULL,          -- agg id
    version    int      NOT NULL,          -- 1,2,3... внутри стрима
    type       text     NOT NULL,
    payload    jsonb    NOT NULL,
    created_at timestamptz NOT NULL DEFAULT now(),
    PRIMARY KEY (stream_id, version)       -- защита от конкурентной записи
);

Первичный ключ (stream_id, version) и есть оптимистичная блокировка: два конкурентных процесса, прочитавших версию 7, попытаются вставить версию 8 - один получит конфликт и перечитает.

Что покупает и сколько стоит

Что решает API Gateway

• Единая точка входа и роутинг. Клиент знает один домен, а внутренняя топология его не касается. Сервисы можно делить и переименовывать, не трогая клиентов.
• Терминация TLS и mTLS внутрь. Сертификаты в одном месте.
• Аутентификация. Проверка подписи JWT / интроспекция токена делается один раз, дальше внутрь идёт проверенный контекст (заголовки с subject, scope, tenant). Аутентификацию gateway берёт на себя, авторизацию нет (об этом ниже).
• Rate limiting и квоты по клиенту/ключу/IP, защита от всплесков и абьюза.
• Сквозная наблюдаемость. Генерация trace_id/request_id, единые метрики и логи по всему внешнему трафику: на «сколько 5xx у нас снаружи» отвечает один дашборд.
• Развязка версий и протоколов. Снаружи REST/JSON, внутри gRPC; наружу /v1, внутри уже v3.
• Инфраструктурные мелочи, которых иначе N копий: CORS, сжатие, размер тела, таймауты, канареечный роутинг по заголовку, allowlist эндпоинтов.

Что в gateway класть нельзя

Правило простое: gateway не должен знать домен. Как только в конфигурации появляется «если order.total > 10000, отправить в другой сервис» или «склеить ответы и посчитать скидку», начинается ESB-паттерн из 2005-го: центральный узел с бизнес-правилами, который релизится отдельно, ломает всех и становится узким местом организационно (очередь на изменение конфига) и технически. Проверить просто: если для новой фичи нужен релиз gateway - граница проведена неверно.

BFF: backend for frontend

Проблема, которую он решает: у мобильного приложения, веба и партнёрского API разные потребности. Мобильному нужен один запрос с минимумом байт (батарея, сеть), вебу богатый ответ, партнёру стабильный контракт на годы. Общий API, который пытается устроить всех, устраивает никого: он либо переусложнён параметрами (?include=a,b,c&fields=...), либо заставляет клиента делать 8 запросов на один экран.

BFF работает как слой на клиента: агрегирует вызовы к нескольким сервисам, обрезает лишние поля, приводит формат и принадлежит команде этого клиента. Отличие от gateway: gateway один и доменно-нейтрален, BFF-ов несколько и они знают про конкретный UI. Логика в BFF допустима, но только презентационная: «на экране заказа показываем адрес, статус и три последних события» - это про экран, а не про домен.

Service discovery

Поды переезжают, инстансы автоскейлятся, и статический список адресов в конфиге не живёт. Нужен реестр: инстанс при старте регистрируется и шлёт heartbeat, при остановке снимается, а клиент получает актуальный список.

• Client-side discovery. Клиент сам запрашивает реестр (Consul, etcd, Eureka) и сам балансирует. Плюсы: умная балансировка (least-request, learning от латентности) и нет лишнего хопа. Минус: логика едет в каждый клиент на каждом языке.
• Server-side discovery. Клиент бьёт в стабильный адрес (k8s Service, ELB), балансировкой занимается инфраструктура. Клиент от этого тупеет, и это плюс, но добавляется лишний хоп и слабый контроль стратегии. В Kubernetes это по умолчанию: DNS-имя svc.ns.svc.cluster.local плюс kube-proxy/iptables.
• Health checks. Реестр обязан быстро выкидывать мёртвые инстансы, иначе клиенты будут упорно бить в труп. Разделяй liveness («перезапусти меня») и readiness («не шли мне трафик») - путаница между ними даёт либо рестарт-луп, либо 502 при деплое.
• Залипание на старом адресе, классические грабли: под переехал, а клиент продолжает бить в прежний IP. Сам резолвер Go ответы не кэширует - держат адрес кэш ОС и живые соединения в пуле, для которых адрес спрашивали один раз. В gRPC лечится резолвером с подпиской, в HTTP - временем жизни соединения: IdleConnTimeout и CloseIdleConnections.

Конфигурация

• Разделение по природе. Код в образе, конфиг в окружении, секреты - в хранилище секретов (Vault, KMS, k8s Secret с монтированием файлом и ротацией). Env-переменная для секрета плоха тем, что видна в /proc/<pid>/environ и в дампах (а вписанная в манифест значением, без Secret, — ещё и в kubectl describe), и ротируется только рестартом.
• Статическая vs динамическая. Статическая читается на старте (адрес БД, размер пула). Динамическая должна меняться без рестарта: фича-флаги, лимиты, семплирование логов, аварийные переключатели. Для второй нужен watch/pull с валидацией и безопасным дефолтом при недоступности источника.
• Валидация на старте, fail fast. Отсутствующий или бессмысленный параметр роняет приложение при запуске с внятным сообщением, а не nil-паникой через час под нагрузкой.
• Конфиг-сервис становится единой точкой отказа, если приложение не стартует без него. Лечится кэшем последней валидной конфигурации на диске.

Service mesh

Идея: вынести всю сетевую обвязку из библиотек приложения в sidecar-прокси (Envoy в каждом поде рядом с приложением) или в общий прокси на узле (ambient-режим Istio; Cilium часть работы делает прямо в ядре через eBPF). Приложение ходит по обычному адресу сервиса и о перехвате не знает: трафик молча заворачивают на прокси (iptables или eBPF), а он делает всё остальное.

Цена: +1 контейнер и +2 сетевых хопа на каждый запрос (обычно единицы миллисекунд, но на внутренних вызовах в 1 мс это удвоение), заметный расход CPU/памяти на sidecar-ы, сложная плоскость управления, которую надо уметь чинить в 3 часа ночи, и новый класс инцидентов («запросы не идут, потому что sidecar стартовал позже приложения»). На собесе это звучит так: «mesh окупается примерно от нескольких десятков сервисов и/или при жёстком требовании mTLS и zero-trust; на пяти сервисах это дороже, чем библиотека с ретраями и circuit breaker».

Что считается ломающим изменением

Отдельная ловушка: enum. Новый статус добавить безопасно, только если потребители написаны толерантно; если у кого-то switch с default: panic, аддитивное изменение уронит его в проде. Отсюда правило: «новое значение enum ломает совместимость, пока не доказано обратное».

Стратегии версионирования

• Аддитивность + tolerant reader. Основной механизм: не удалять, не менять типы, игнорировать незнакомые поля при разборе. В protobuf это встроено: номера полей неизменны, неизвестные поля сохраняются, удалённые номера помечаются reserved, чтобы их никто не переиспользовал.
• Версия в URL (/v1/orders) - просто, видно в логах, легко роутить на gateway; минус в дублировании кода при живых v1 и v2.
• Версия в медиа-типе (Accept: application/vnd.acme.v2+json): чище с точки зрения REST, хуже для отладки и кэширования.
• Версия в имени топика или типа события (order.paid.v2). Для брокеров это самый практичный вариант: старые потребители продолжают читать старый топик, пока не мигрируют. Плюс schema registry с проверкой совместимости (BACKWARD/FORWARD/FULL) на этапе публикации схемы - то есть ломающее изменение не проходит в CI.
• Обязательное перекрытие. Порядок выкатки: сначала расширить (сервер поддерживает и старое, и новое), затем мигрировать потребителей, затем удалить старое. Это тот же expand–migrate–contract, что и для схемы БД, и точно так же нельзя делать шаги одновременно.
• Политика вывода версии из эксплуатации: объявленный срок, метрика «кто ещё ходит в v1» с разбивкой по клиентам, письма владельцам, только потом удаление. Без метрики использования удаление превращается в русскую рулетку.

Consumer-driven contracts

Интеграционные тесты «поднимем всё вместе» медленные и хрупкие, да ещё требуют собрать всю систему на каждый коммит. CDC переворачивает подход. Каждый потребитель описывает, что именно ему нужно от провайдера: конкретные запросы и ожидаемые куски ответов. Этот пакт публикуется в общий брокер контрактов (Pact Broker и аналоги).

1. Тест на стороне потребителя гоняется против мока, сгенерированного из пакта, так что живой провайдер ему не нужен.
2. Пакт публикуется в брокер с версией потребителя.
3. В CI провайдера запускается верификация: реальный провайдер проверяется против всех пактов всех потребителей. Красный билд означает «твоё изменение сломает вот этих».
4. Перед деплоем спрашиваем брокер: «совместима ли эта версия провайдера со всем, что сейчас в проде?» (can-i-deploy).

Главная ценность в том, что провайдер узнаёт о поломке в своём CI за минуты, а не от соседней команды через неделю. Побочная: пакты показывают, какие поля реально кем-то используются, и неиспользуемое можно спокойно удалять. Ограничение: CDC проверяет форму и совместимость, но не бизнес-смысл - если ты изменил значение поля amount с копеек на рубли, все пакты останутся зелёными.