Архитектура и системный дизайн

Формулировка, которую ждут: каждый слой знает только про слой ниже, и никогда наоборот. Транспорт знает про сервис, сервис — про интерфейсы репозиториев, репозиторий — про SQL. Обратных импортов нет вообще: service не должен уметь собрать HTTP-ответ, а repository не должен знать, кто его вызвал и зачем.

Что это покупает

• Транспорт меняется, логика остаётся. Появился gRPC или консольная команда, дописываешь ещё один адаптер поверх того же сервиса. Если бизнес-правила размазаны по хендлерам, второй транспорт означает копипасту правил.
• Тестируемость. Сервис тестируется без БД и без HTTP: подставил фейковый репозиторий, проверил сценарий. Это самые дешёвые и самые полезные тесты в проекте.
• Изменения не расползаются. Поменялась схема таблицы, правишь репозиторий. Поменялся формат ответа API, правишь транспорт. Поменялось правило скидки, правишь сервис. Если правка одного требования трогает все три слоя, границы проведены неправильно.

Как это ломают

Три классических нарушения. Первое, «анемичный сервис»: хендлер сам ходит в репозиторий, сам считает, сам решает; сервис остаётся тонкой прослойкой-делегатом и никакой ценности не несёт. Второе: транспорт протекает вниз, в сервис прилетает *gin.Context или http.ResponseWriter, и тестировать его теперь нельзя без поднятия сервера. Третье: хранилище протекает вверх, наружу возвращается *sql.Rows или структура с gorm-тегами, и домен оказывается формой таблицы.

В наивной трёхслойке цепочка импортов такая: handler → service → postgres. Домен в самом низу зависит от драйвера БД. Гексагональная (она же «порты и адаптеры», она же ядро Clean Architecture) разворачивает это: service объявляет интерфейс UserRepo у себя, а пакет postgres импортирует service, чтобы этот интерфейс реализовать. Домен теперь не импортирует ничего, кроме стандартной библиотеки. Это и есть Dependency Inversion из SOLID, применённый к границе процесса.

Ports and adapters, конкретно

• Driving-порты (входящие, «слева») описывают, что домен предлагает миру: интерфейс юзкейса. Адаптеры: HTTP-хендлер, gRPC-сервер, consumer Kafka, cron-команда.
• Driven-порты (исходящие, «справа») говорят, что домену нужно от мира: UserRepo, Mailer, PaymentGateway, Clock. Адаптеры: Postgres, SMTP, HTTP-клиент, time.Now.
• Composition root остаётся единственным местом (main), где конкретные адаптеры встречаются с портами.

Практический выигрыш измеряется не красотой схемы, а тем, сколько тестов работают без Docker. Когда все внешние эффекты спрятаны за портами, весь домен покрывается быстрыми юнит-тестами, а тестконтейнеры нужны только адаптерам. Второй выигрыш: время больше не просачивается в код случайно, Clock как порт снимает флаки в тестах на таймауты и TTL.

Когда это оверинжиниринг

Когда домена нет. Если сервис просто проксирует БД (CRUD, фильтры, пагинация), то «домен» состоит из структуры и валидации, и три слоя абстракций вокруг него означают, что новое поле придётся дописывать в шести файлах. Признаки лишнего: интерфейс ровно с одной реализацией, которая никогда не менялась; маппинг структуры в структуру без единого изменения полей; папка usecase, где в каждом файле один метод, дёргающий один метод репозитория. Честная позиция на собесе: «начинаю с плоской структуры, инвертирую зависимость там, где реально появилась вторая реализация или где мне мешает тестировать».

Канон: у каждого компонента есть New…, принимающий интерфейсы своих зависимостей и возвращающий готовый к работе объект. Всё связывание происходит в одном месте, в main (composition root). Граф зависимостей виден глазами, порядок инициализации и закрытия ресурсов явный, компилятор проверяет типы. Это и есть «DI без магии».

func main() {
    cfg := config.MustLoad()

    db, err := pgxpool.New(ctx, cfg.DSN)      // ресурсы создаются сверху вниз,
    if err != nil { log.Fatal(err) }
    defer db.Close()                          // закрываются снизу вверх

    repo := postgres.NewUserRepo(db)          // адаптер реализует порт
    mailer := smtp.NewMailer(cfg.SMTP)
    svc := user.NewService(repo, mailer, clock.System{})
    h := httpapi.NewHandler(svc, logger)

    srv := &http.Server{Addr: cfg.Addr, Handler: h.Routes()}
    // ... graceful shutdown
}

Когда становится больно

Когда в main набирается 300 строк проводки и новую зависимость приходится протаскивать через пять конструкторов. Тогда есть два ответа. wire (Google) генерирует код: ты описываешь провайдеры, go generate выдаёт обычный Go-файл с той же ручной проводкой. Ошибки вылезают на компиляции, рантайм не платит ничего, в отладке видно нормальный код. fx (Uber) собирает граф в рантайме через рефлексию: удобные жизненные циклы (OnStart/OnStop), группы, декораторы, но ошибки графа всплывают при старте, а стектрейсы становятся неприятными.

В Java или C# интерфейс объявляется вместе с реализацией, потому что класс обязан явно сказать implements. В Go этого нет: любой тип с подходящим набором методов автоматически удовлетворяет интерфейсу. Значит, интерфейс можно объявить где угодно, и правильное место там, где он используется. Пакет-потребитель описывает минимальный контракт, который ему нужен, а пакет-реализация о нём даже не знает.

// Плохо: пакет-производитель объявляет широкий интерфейс "на всякий случай"
package postgres
type Storage interface {   // 20 методов; потребителю нужен один
    GetUser(...)   ; SaveUser(...)  ; ListUsers(...)
    GetOrder(...)  ; SaveOrder(...) ; /* ... */
}

// Хорошо: потребитель просит ровно то, что использует
package notify
type userGetter interface {                       // с маленькой буквы: деталь пакета
    ByID(ctx context.Context, id user.ID) (*user.User, error)
}
type Notifier struct {
    users userGetter
}
func New(u userGetter) *Notifier { return &Notifier{users: u} }

Что это даёт по шагам

• Мок пишется в две строки и лежит рядом с тестом: ни gomock, ни правка чужого пакета не нужны.
• Циклы импорта рвутся. Стрелка разворачивается: раньше notify импортировал postgres, теперь никто никого.
• Честный ISP. Интерфейс с одним методом не получится «раздуть на будущее» — он ровно такой, каким его требует код.
• Устойчивость к изменениям. Добавили метод в конкретный тип — ни один потребитель не сломался, потому что их контракты уже, чем реализация.

Обратная сторона правила: возвращать надо конкретный тип. Если конструктор отдаёт интерфейс, потребитель теряет доступ к новым методам, доку становится читать сложнее, и появляется классическая ловушка Go — «типизированный nil в интерфейсе»: функция вернула (*MyErr)(nil), а сравнение err != nil дало true.

Что означает каждая папка

• cmd/<binary>/main.go даёт по папке на бинарь. Внутри только разбор конфига, сборка графа зависимостей и запуск. Логики здесь нет: всё, что в main, невозможно импортировать и тяжело тестировать.
• internal/ остаётся единственной папкой со смыслом на уровне языка. Пакет внутри internal импортируется только из поддерева его родителя. Это защита от того, что чужой сервис начнёт зависеть от твоих внутренностей и ты никогда не сможешь их поменять. По умолчанию весь код сервиса живёт здесь.
• pkg/ означает «код, который мы разрешаем импортировать снаружи». В проекте с одним сервисом это лишний уровень вложенности. Заводить его стоит, только когда у тебя есть внешние потребители и ты готов держать обратную совместимость.
• В api/ лежат proto/OpenAPI-схемы, в migrations/ SQL, в deploy/ манифесты. Это уже вкусовщина, но она предсказуемая.

Package-oriented design

Идея Билла Кеннеди: пакет задаёт зону ответственности, а не категорию типов. Нарезка models/, services/, handlers/, utils/ группирует по «что это за штука», из-за чего одна фича размазывается по четырём папкам, а импорты неизбежно закольцовываются. Нарезка user/, order/, billing/ группирует по «про что это», и тогда фича живёт в одном месте, а имя пакета работает на читаемость: user.Service, а не services.UserService (заикание user.UserService выдаёт ту же неправильную нарезку). Отдельно под запретом пакет utils/common/helpers: склад без границы, который со временем импортирует всё и становится источником циклов.

Монорепа

Монорепа выигрывает, когда сервисы делает одна команда и они меняются вместе: атомарный коммит через границу сервиса, единые версии зависимостей, общий тулинг и линтеры, простой shared-код без публикации библиотек, честный «сломал контракт — увидел сразу». Проигрывает, когда репозиторий вырастает настолько, что CI начинает собирать всё на любое изменение (лечится go work, тегами и селективной сборкой по изменённым путям), и когда разные команды хотят разный релизный цикл и разные права доступа. Практичный ответ: «пока команда одна и сервисов меньше десятка, монорепа почти всегда дешевле; боль начинается на масштабе CI, и лечится она тулингом, а не разделением репозиториев».

S — Single Responsibility

«У модуля должна быть одна причина для изменения» — причина, а не действие. Классический антипример: OrderService, который валидирует, считает налог, пишет в БД, шлёт письмо и отдаёт PDF. Его меняют бухгалтерия, маркетинг и DBA — три причины, три источника конфликтов. Разбиваешь на Validator, TaxCalculator, Repository, Notifier, а сам сервис становится сценарием, который их вызывает.

O — Open/Closed

Расширять поведение без правки существующего кода. В Go это делается не наследованием, а функциями и интерфейсами: реестр стратегий, куда регистрируются новые обработчики, или functional options, куда добавляется новая опция.

// Было: switch, который правят при каждом новом типе оплаты
switch method {
case "card":   ...
case "sbp":    ...
}

// Стало: новая оплата = новый файл, старый код не трогаем
type PaymentMethod interface {
    Charge(ctx context.Context, amount Money) (TxID, error)
}
type Registry struct {
    m map[string]PaymentMethod
}
func (r *Registry) Register(name string, p PaymentMethod) { r.m[name] = p }

L — Liskov Substitution

Наследования в Go нет, но LSP никуда не делся: любая реализация интерфейса обязана вести себя так, как обещает контракт. Контракт нарушает реализация, которая на половине методов возвращает errors.New("not supported"), или Read, который не возвращает io.EOF, или репозиторий, который вместо ErrNotFound отдаёт nil, nil. Код, написанный против интерфейса, ломается при подстановке, и это нарушение LSP. В контракт входят сигнатуры, а вместе с ними ошибки, блокирующее поведение и потокобезопасность.

I — Interface Segregation

Много маленьких интерфейсов лучше одного большого. Эталон держит стандартная библиотека: io.Reader и io.Writer по одному методу, а io.ReadWriteCloser собирается композицией. Практическое правило: если реализациям приходится писать заглушки — интерфейс слишком широкий.

D — Dependency Inversion

Оба уровня зависят от абстракции, и объявляет её верхний уровень. Именно поэтому в Go интерфейс живёт у потребителя: service объявляет UserRepo, postgres его реализует, и стрелка импорта идёт снизу вверх, к домену.

Functional options — почему именно они

type Option func(*Server)

func WithTimeout(d time.Duration) Option { return func(s *Server) { s.timeout = d } }
func WithLogger(l *slog.Logger) Option   { return func(s *Server) { s.log = l } }

func New(addr string, opts ...Option) *Server {
    s := &Server{addr: addr, timeout: 30 * time.Second, log: slog.Default()} // умолчания
    for _, o := range opts { o(s) }
    return s
}

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

Decorator = middleware

type Middleware func(http.Handler) http.Handler

func WithLogging(log *slog.Logger) Middleware {
    return func(next http.Handler) http.Handler {
        return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
            start := time.Now()
            next.ServeHTTP(w, r)
            log.Info("req", "path", r.URL.Path, "dur", time.Since(start))
        })
    }
}
// Порядок важен: первый в списке становится самым внешним
func Chain(h http.Handler, ms ...Middleware) http.Handler {
    for i := len(ms) - 1; i >= 0; i-- { h = ms[i](h) }
    return h
}

Три реальные причины заводить репозиторий: сервис тестируется без базы; маппинг «строка → доменный тип» лежит в одном месте; SQL не растекается по хендлерам. Причина, которую называют чаще всего и которая почти всегда ложная, звучит так: «сможем сменить Postgres на Mongo». Не сможем. Транзакции, блокировки, уникальные индексы и модель консистентности интерфейсом не абстрагируются.

// domain/user: интерфейс объявлен там, где используется
type Repository interface {
    ByID(ctx context.Context, id ID) (*User, error)
    ByEmail(ctx context.Context, email string) (*User, error)
    Create(ctx context.Context, u *User) error
    Update(ctx context.Context, u *User) error
}

var (
    ErrNotFound      = errors.New("user not found")
    ErrAlreadyExists = errors.New("user already exists")
)

// storage/postgres: адаптер переводит ошибки драйвера в доменные
func (r *UserRepo) ByID(ctx context.Context, id user.ID) (*user.User, error) {
    const q = `SELECT id, email, name, created_at FROM users WHERE id = $1`
    var u user.User
    err := r.db.QueryRow(ctx, q, id).Scan(&u.ID, &u.Email, &u.Name, &u.CreatedAt)
    switch {
    case errors.Is(err, pgx.ErrNoRows):
        return nil, fmt.Errorf("user %s: %w", id, user.ErrNotFound)  // %w сохраняет sentinel
    case err != nil:
        return nil, fmt.Errorf("select user %s: %w", id, err)
    }
    return &u, nil
}

func (r *UserRepo) Create(ctx context.Context, u *user.User) error {
    _, err := r.db.Exec(ctx, `INSERT INTO users (...) VALUES (...)`, ...)
    var pgErr *pgconn.PgError
    if errors.As(err, &pgErr) && pgErr.Code == "23505" {   // unique_violation
        return fmt.Errorf("email %s: %w", u.Email, user.ErrAlreadyExists)
    }
    return err
}

Почему именно так

• nil, nil перекладывает на вызывающего обязанность помнить про проверку; рано или поздно кто-то забудет и получит панику вместо 404.
• (*User, bool, error) возвращает три значения на каждый вызов, конструкция if !ok плодится по всему коду и путается с err != nil.
• sql.ErrNoRows наружу тащит деталь драйвера в бизнес-логику; при переходе с database/sql на pgx (там свой pgx.ErrNoRows) сломается весь сервис.
• Sentinel + errors.Is позволяют транспорту в одном месте отобразить домен в HTTP: ErrNotFound → 404, ErrAlreadyExists → 409.

Порядок действий

1. Характеристические тесты (Майкл Физерс). Не «правильные», а фиксирующие текущее поведение, включая странности. Golden-файлы: прогнал реальные входы, записал выходы, закоммитил. Теперь любое изменение поведения видно как diff.
2. Найти швы (seams). В Go это значит вытащить наружу time.Now, http.Get, os.Getenv, глобальные переменные, прямые db.Query, и сделать их полями структуры или параметрами.
3. Вынести чистые функции. Куски без ввода-вывода покрываются тестами первыми и ломаются заметнее всего.
4. Разрезать по данным. Смотришь, какие поля используются какими методами вместе. Метод, трогающий три поля из двадцати, просится в отдельный тип. Это самый надёжный критерий границы — куда надёжнее, чем «по смыслу».
5. Переносить по одному методу, оставляя в старом объекте делегирующий вызов. Каждый шаг компилируется, каждый шаг деплоится.
6. Удалить делегаты, когда все вызовы переехали. Компилятор Go найдёт остатки.

Что говорить про процесс

Рефакторинг идёт в основной ветке маленькими коммитами, а не в трёхмесячной ветке. Переименование и перенос разводи по разным коммитам, иначе diff нечитаем и ревью формально. Если поведение обязано измениться, ставь feature flag, чтобы старый и новый путь жили рядом и можно было сравнить результаты на проде (shadow-запуск). И заранее договорись о метрике успеха: размер файла, число зависимостей пакета, время сборки, покрытие. Иначе процесс не заканчивается.

Запрет не каприз: без циклов у компилятора есть однозначный топологический порядок инициализации пакетов (переменные уровня пакета, затем init()), и каждый пакет можно компилировать независимо и кэшировать. В языках, где циклы разрешены, порядок инициализации становится источником трудноуловимых багов.

Четыре способа разорвать

1. Интерфейс у потребителя. Работает почти всегда: order объявляет у себя type userGetter interface{ ByID(...) }, и импорт order → user исчезает, а user о нём и не знал.
2. Общий нижний пакет. Типы, нужные обоим, уезжают в internal/domain (или entity), от которого зависят оба, а он — ни от кого.
3. Слить пакеты. Если два пакета взаимно нужны друг другу постоянно, это чаще всего одна зона ответственности, разрезанная искусственно.
4. Инвертировать через события. Вместо прямого вызова user → notify пакет user публикует событие в шину, а notify подписывается; оба зависят от пакета с типами событий.

Практический канон

• Приоритет один на все сервисы и задокументирован. Какой именно, дело вкуса; важно, чтобы он не менялся от проекта к проекту.
• Fail fast. Невалидный конфиг убивает процесс на старте, а не через два часа на первом обращении к редкой ручке. В k8s это правильно: под не пройдёт readiness и старая версия останется жить.
• Конфиг не глобал. Разобрали структуру в main, дальше передаём куски в конструкторы. os.Getenv посреди бизнес-логики прячет зависимость: её не видно в графе и не подменить в тесте.
• Типы, а не строки. time.Duration, int, url.URL разбираются и проверяются на старте, чтобы потом не гадать: «таймаут тут в миллисекундах или в секундах?».

12-factor: что реально спрашивают

• III. Config в окружении. В репозитории конфигов стендов быть не должно, а новый стенд не должен требовать релиза.
• VI. Stateless-процессы: никакого состояния в памяти между запросами. Сессии в Redis, файлы в объектном хранилище. Иначе не масштабируется горизонтально и теряется при рестарте.
• IX. Disposability требует быстрого старта и корректной реакции на SIGTERM: перестать принимать новое, дожать текущее, закрыть коннекты. Прямая связка с graceful shutdown и с тем, как k8s выкатывает поды.
• XI. Логи в stdout. Приложение не занимается ротацией и файлами, это работа окружения.
• X. Dev/prod parity: одинаковые версии зависимостей и одинаковый способ запуска, отсюда популярность docker-compose для локальной разработки.

Разложить по осям, а не «лучше/хуже»

Монолит выигрывает в скорости разработки, отладке, консистентности и стоимости инфраструктуры. Микросервисы выигрывают в независимости деплоя, точечном масштабировании и изоляции отказов, причём изоляция не появляется сама, её надо построить таймаутами, circuit breaker и деградацией. Есть оси, где выигрыш неоднозначен: онбординг (в монолит вход дольше, но система понятна целиком), технологическая свобода (чаще зоопарк, чем польза).

Почему monolith first

• Границы неизвестны. В новом продукте домен переопределяют каждую неделю. Ошибка в границе внутри монолита стоит рефакторинга; между сервисами миграции данных, версий API и координации релизов.
• Налог платится сразу, польза приходит потом. Оркестратор, трейсинг, брокер, пайплайны съедают месяцы, которые продукт может не пережить.
• Склеивать обратно дороже, чем резать. Публичных историй возврата к монолиту (Segment, Amazon Prime Video) больше, чем историй «мы жалеем, что начали с монолита».

Когда исключение оправдано

Если организация уже знает домен (делает второй похожий продукт), у неё есть платформа и опыт эксплуатации, и сразу несколько команд, то стартовать несколькими сервисами разумно. Законен и отдельный сервис под чужой стек (ML на Python) или под другой профиль нагрузки: это точечное решение, а не общий распил.

Пять правил

1. Модуль = пакет с узким публичным API. В Go за это отвечает сам язык: internal/order/internal/… компилятор не даст импортировать никому, кроме поддерева order. Наружу торчат order.Service и доменные типы, остальное закрыто.
2. Общение через порты, а не через чужие репозитории. order объявляет у себя UserProvider с одним методом; адаптер к user.Service собирается в main.
3. Данные разделены. Отдельные схемы Postgres на модуль и запрет на JOIN между ними. Это самое неудобное и самое ценное правило: именно совместные JOIN-ы делают распил невозможным через два года.
4. События внутри процесса. Там, где связь по смыслу «уведомить, а не запросить», модуль публикует событие в шину в памяти. При распиле шину меняют на Kafka, а модули править не приходится.
5. Границы проверяются в CI. go-arch-lint или depguard с правилами импортов. Без автоматической проверки границы разъезжаются за квартал.

Что это даёт при распиле

Вынос модуля превращается в механическую операцию: реализация порта заменяется на HTTP/gRPC-клиент, таблицы модуля переезжают в свою базу, шина в памяти — в брокер. Никакого «сначала полгода распутываем» не требуется. Плюс можно резать по одному модулю за раз и останавливаться в любой момент, многие команды так и живут: два-три вынесенных сервиса и большое модульное ядро.

Признаки, которые считаются

• Организационный. Время от «готово» до «на проде» измеряется днями; команды ждут релизного поезда и друг друга. Это единственный признак, который прямо указывает на микросервисы.
• Ресурсный. Один модуль требует 32 ГБ, остальным нужно 2, и платим за максимум, умноженный на число подов. Или один модуль на GPU, а остальные нет.
• Надёжностный. Утечка памяти в отчётах кладёт приём платежей; нет способа изолировать ресурсы внутри одного процесса.
• SLA. Платежи хотят 99.99 %, админка — 99 %, а деплоятся вместе, значит, по факту у обоих SLA админки.
• Инженерный. Сборка и тесты дольше получаса, флаки, «прогоню ещё раз». Обратная связь порвалась.

Что делать, и не всегда это распил

1. Сначала дешёвое. Вертикальное масштабирование, кэш, индексы, профилирование. Часто «потолок» оказывается одним неудачным запросом. Распил медленного кода делает его медленным и распределённым.
2. Разделить деплой одного бинаря по ролям. Один и тот же артефакт запускается с разными флагами: --role=api, --role=worker, --role=cron. Это даёт независимое масштабирование и изоляцию отказов почти бесплатно, без распила кода и без сети между модулями.
3. Навести модульность внутри. Разделить схемы БД, убрать межмодульные JOIN-ы, поставить линтер импортов. Это подготовка к распилу, которая полезна, даже если распила не будет.
4. Вынести первый сервис strangler-фигом. Самый изолированный кусок, ради тренировки инфраструктуры.
5. Резать дальше только под конкретную боль. Каждый следующий сервис должен закрывать названный признак из списка выше, а не «продолжать начатое».

Strangler fig

Метафора фикуса-душителя: новое обвивает старое и постепенно его вытесняет. Шаги: ставим reverse proxy перед монолитом (сначала он просто проксирует всё) → выбираем самый изолированный кусок → разделяем данные внутри монолита, убирая JOIN-ы → пишем сервис и гоняем его в тени, сравнивая результаты → переключаем маршрут на фасаде по проценту трафика → удаляем старый код. Последний шаг пропускают чаще всего, и тогда получаются два источника правды.

Выделение по bounded context

Это ответ на вопрос «что резать», а strangler fig — на вопрос «как резать». Ищем места, где меняется смысл терминов и где данные не пересекаются; первым выносим кусок с минимальным числом связей, а не самый бизнес-важный. Порядок «данные → код → трафик» здесь обязателен: пока таблицы общие, вынесенный сервис не самостоятелен.

Branch by abstraction

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

Распределённый монолит: признаки

• Общая база: два сервиса пишут в одну таблицу.
• Релиз только «поездом», в определённом порядке, и откатывать надо по порядку.
• Длинные синхронные цепочки: один запрос порождает 5–10 последовательных вызовов.
• Общая библиотека доменных типов: правка в ней требует пересборки всех.
• Сервис нельзя поднять и протестировать в одиночку.

Почему это хуже обоих вариантов: от монолита потеряли транзакции, дешёвый рефакторинг и простую отладку; от микросервисов не получили независимый релиз и изоляцию отказов. Остаются только издержки. Выход не в том, чтобы «доводить распил»: сначала надо разделить данные и убрать синхронные цепочки, заменить часть вызовов событиями, добавить кэш/реплику данных вместо запроса к соседу, ввести версионирование контрактов, чтобы релизы расцепились.

Bounded context

Идея DDD в том, что универсальной модели предметной области не существует, существуют контексты, внутри каждого из которых термин значит ровно одно. В корзине «заказ» это черновик с позициями, в доставке — адрес, вес, маршрут, в бухгалтерии — сумма, НДС, документ. Попытка сделать одну структуру Order на всех даёт объект с сорока полями, половина которых всегда пустые, и намертво связывает три команды. Между контекстами модели переводятся явно, этим занимается anticorruption layer, слой, который защищает твою модель от чужой (и от легаси-монолита при распиле).

Практические критерии, по убыванию надёжности

1. По данным. Сервис эксклюзивно владеет своими таблицами и остаётся единственным источником правды. Если сценарий требует транзакции по таблицам двух сервисов, граница неверна. Это самый сильный и самый проверяемый сигнал.
2. По причине изменения. Смотри историю git: что всегда меняется вместе, должно жить вместе. SRP на уровне системы.
3. По языку. Меняется словарь бизнеса — меняется контекст. Если аналитики двух отделов под одним словом понимают разное, это готовая граница.
4. По команде (закон Конвея). Архитектура повторит структуру коммуникаций. Если границы сервисов не совпали с границами команд, победят команды. При «обратном манёвре Конвея» команды строят сначала, под желаемую архитектуру.
5. По нагрузке и SLA. Другой профиль трафика или другая требуемая доступность дают законный повод, даже для небольшого куска домена.

Сеть

Вызов метода занимает единицы наносекунд. RPC внутри датацентра сотни микросекунд плюс сериализация: разница в пять-шесть порядков. Но главное не скорость, а то, что сеть ненадёжна: появляются таймауты, ретраи, дубликаты и частичные отказы, и всё это просачивается в бизнес-логику. Отдельно бьёт умножение доступностей: цепочка из пяти сервисов по 99.9 % даёт 99.5 %, и это без учёта латентности хвостов.

Консистентность

Транзакции между сервисами нет. Каждый сценарий, который раньше был одним BEGIN … COMMIT, становится сагой с компенсирующими действиями, transactional outbox для надёжной публикации событий и идемпотентными обработчиками для защиты от дублей. Это отдельная подсистема с собственным состоянием, мониторингом и багами, самая недооценённая статья расходов.

Наблюдаемость

Без distributed tracing, единого сбора логов с общим trace_id и метрик по каждому исходящему вызову отладка становится гаданием: «медленно» может быть в любом из десяти мест. Это отдельный стек (OpenTelemetry + Jaeger/Tempo + Prometheus + Loki) со своей стоимостью хранения и своей эксплуатацией. В монолите то же самое даёт обычный стектрейс.

Инфраструктура и люди

• Оркестратор, реестр образов, service discovery, управление секретами, брокер.
• N пайплайнов CI/CD, N наборов дашбордов и алертов, дежурства и рантбуки.
• Средства локальной разработки, иначе человек не может воспроизвести баг.
• Версионирование контрактов и contract-тесты, чтобы релизы не ломали соседей.
• Дублирование справочных данных между сервисами и их синхронизация.
• Когнитивная нагрузка и владение: без карты сервисов появляются «сироты», которые все боятся трогать.

Тут два разных измерения, которые постоянно смешивают. Первое отвечает за синхронность вызова: блокируется ли вызывающий до ответа. Второе смотрит на направление знания: знает ли отправитель, кто его слушает. Можно сделать асинхронный запрос-ответ через очередь (вызывающий всё равно логически ждёт ответ) и можно сделать синхронную публикацию через 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 доставка.
• Идемпотентность + повтор до успеха. Если операция идемпотентна, «не знаю, прошло ли» лечится повтором, и половина проблемы исчезает.
• Сверка (reconciliation). Фоновый процесс, который сравнивает состояния двух сервисов и чинит расхождения. В финтехе это обязательный элемент, а не костыль: любая распределённая система рано или поздно расходится, и вопрос только в том, заметишь ты это сам или тебе скажет клиент.

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

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

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

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

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

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

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

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

Как работает

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, в kubectl describe и в дампах, и ротируется только рестартом.
• Статическая vs динамическая. Статическая читается на старте (адрес БД, размер пула). Динамическая должна меняться без рестарта: фича-флаги, лимиты, семплирование логов, аварийные переключатели. Для второй нужен watch/pull с валидацией и безопасным дефолтом при недоступности источника.
• Валидация на старте, fail fast. Отсутствующий или бессмысленный параметр роняет приложение при запуске с внятным сообщением, а не nil-паникой через час под нагрузкой.
• Конфиг-сервис становится единой точкой отказа, если приложение не стартует без него. Лечится кэшем последней валидной конфигурации на диске.

Service mesh

Идея: вынести всю сетевую обвязку из библиотек приложения в sidecar-прокси (Envoy рядом с каждым подом) или в ядро (eBPF/ambient-режим). Приложение думает, что делает простой HTTP-запрос на localhost, а прокси делает всё остальное.

Цена: +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 с копеек на рубли, все пакты останутся зелёными.

Скелет ответа за минуту

1. Дать точные определения: C значит линеаризуемость (система выглядит как одна копия); A требует, чтобы каждый живой узел отвечал непустым корректным ответом за конечное время; P описывает работу при потере сообщений между группами узлов.
2. Сказать, что теорема условная. Пока сеть цела, есть и C, и A. Выбор возникает ровно в момент разрыва.
3. Разобрать сценарий на двух узлах: клиент записал x=2 в A, сеть порвалась, другой клиент читает у B. У B два варианта: ответить ошибкой (CP) или ответить x=1 (AP). Третьего нет.
4. Привести примеры: etcd/ZooKeeper/Consul/Spanner работают как CP (меньшинство отключает себя), Cassandra/DynamoDB/Riak как AP (отвечают всегда, конфликты чинят потом).
5. Добавить, что это настройка, а не природа: в Cassandra QUORUM против ONE буквально переключает CP/AP на уровне отдельного запроса.

Почему CA — некорректная категория

Чтобы отказаться от P, надо утверждать, что сетевого разделения не бывает. Но разрыв не сводится к перерубленному кабелю: 30-секундная пауза GC, перегруженный линк, кривая сетевая политика, перезагрузка свитча выглядят снаружи идентично разрыву. Ты не выбираешь, случится ли partition. Выбираешь только реакцию. Формально под CA подходит одиночный узел (сети между узлами нет, разделения не бывает), но у него нет и отказоустойчивости: он просто недоступен, когда падает. Как только появляется вторая реплика, сразу встаёт вопрос «коммитить, если реплика не ответила?» — и это уже C против A.

PACELC

If P then A or C, else L or C. Вторая половина описывает 99.99 % времени: ждать, пока подтвердит кворум (медленнее, консистентно), или ответить с локальной реплики (быстро, возможно устарело). Синхронная кросс-ДЦ репликация стоит десятки миллисекунд на каждый коммит всегда, а не в одной лишь аварии. Классификация: Cassandra/DynamoDB идут как PA/EL, etcd/ZooKeeper/Spanner/MongoDB(majority) как PC/EC, Postgres с асинхронной репликой как PA/EL по пути чтения с реплики.

Крайности

Strict (линеаризуемость): система ведёт себя как одна копия, любое чтение видит последнюю завершённую запись по реальному времени. Добиваются этого лидером плюс синхронной репликацией на кворум или консенсусом. Цена: латентность каждой операции и отказ меньшинства при разделении.

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

Три аномалии, у которых есть имена

Практический рецепт «read-your-writes» для веб-сервиса

// После записи кладём в сессию/куку момент (или LSN) и N секунд читаем с мастера.
const stickyWindow = 3 * time.Second

func (r *Repo) pickConn(ctx context.Context) *sql.DB {
    if t, ok := LastWriteAt(ctx); ok && time.Since(t) < stickyWindow {
        return r.primary          // свои свежие данные только с мастера
    }
    return r.replica              // всё остальное с реплики
}

Точнее работает вариант не по времени, а по позиции: после записи запомнить LSN (pg_current_wal_lsn()), при чтении выбрать реплику, у которой pg_last_wal_replay_lsn() >= запомненного, иначе идти на мастер. В других системах это называют «токен консистентности» или ReadYourWrites-сессия.

Примеры

• Идемпотентно: SET balance = 100; PUT /users/42; DELETE (второй раз просто нечего удалять); INSERT ... ON CONFLICT DO NOTHING; UPDATE ... SET status='paid' WHERE id=$1; загрузка объекта в S3 по фиксированному ключу; Redis SET, SADD.
• Неидемпотентно: balance = balance + 100; POST /orders без ключа; INSERT без уникального ограничения; Redis INCR, LPUSH; отправка письма, SMS, push; печать чека; вызов внешнего платёжного API без idempotency key.

Уточнение, которое любят слышать: идемпотентность и безопасность (safety) различаются. GET и безопасен, и идемпотентен; DELETE идемпотентен, но не безопасен; POST ни то, ни другое. И ещё: ответ может отличаться (204 в первый раз, 404 во второй), а идемпотентность от этого не ломается.

Три способа сделать неидемпотентную идемпотентной

1. Ключ идемпотентности. Клиент генерирует уникальный id намерения и присылает в заголовке Idempotency-Key, переиспользуя его при всех ретраях. Сервер хранит key → (хеш запроса, состояние, сохранённый ответ) и на повтор возвращает сохранённый результат, не выполняя работу. Три детали: хеш тела (поймать «тот же ключ, другое тело» → 422), состояние IN_PROGRESS (два параллельных ретрая не должны стартовать оба → 409), TTL ключей (сутки-неделя, не вечно).
2. Уникальное ограничение в БД. Естественный ключ операции (UNIQUE (order_id, op_type), message_id PRIMARY KEY) и ON CONFLICT DO NOTHING. Самый надёжный вариант, потому что гарантию даёт хранилище, а не дисциплина кода.
3. Условный переход состояния (CAS). Не «списать», а «перевести из PENDING в PAID»: UPDATE ... WHERE id=$1 AND status='PENDING'. Ноль затронутых строк = работа уже сделана. То же самое с версией: WHERE id=$1 AND version=$2. Заодно решает конкурентные обновления.

Таймауты

• Ставятся всегда: вызов без таймаута превращается в утечку горутин, соединений и памяти, которой управляет чужая сторона.
• Значение выбирают из наблюдаемого p99, а не из головы. Таймаут 30 секунд при p99 = 80 мс не защищает ни от чего.
• Бюджет убывает. Клиенту обещано 2 с, первый хоп съел 700 мс — второму остаётся 1.3 с. В Go это проброшенный context, в gRPC дедлайн передаётся по сети автоматически. Без бюджета суммарный таймаут = сумма таймаутов, и клиент отваливается раньше, чем система отвечает.
• Дедлайн должен реально доходить до запроса в БД и отменять работу, иначе процесс продолжает считать ответ, который уже никому не нужен.

Ретраи

Jitter: почему без него плохо

Тысяча клиентов получила ошибку в один и тот же момент. Без jitter все повторят через ровно 1 секунду — и синхронная волна ударит в сервис, который как раз пытается встать. Full jitter (задержка равномерно из [0, cap), где cap растёт экспоненциально) в замерах даёт наименьшую нагрузку, а по времени до успеха идёт вровень с decorrelated jitter, чуть уступая ему. «Экспонента плюс небольшой шум» проигрывает обоим и по работе, и по времени. Тот же приём нужен в TTL кэша и в расписании cron, иначе получишь thundering herd без всяких ретраев.

Retry storm

Сервис D деградировал. C ретраит 3 раза, B ретраит C 3 раза, A ретраит B 3 раза — и до D доходит 27 запросов на один пользовательский. Нагрузка выросла на порядок ровно в момент, когда нужна была разгрузка, и система входит в метастабильный отказ: она не восстанавливается, даже когда исходную причину убрали, потому что причина теперь в самих ретраях.

1. Ретраи на одном уровне. Обычно на самом внешнем или в service mesh; на промежуточных выключены. Ретраит mesh — приложение не ретраит.
2. Retry budget: ретраи не более ~10 % от объёма основных запросов; превысили порог — ретраи временно запрещены.
3. Circuit breaker поверх: перестать долбить того, кто явно лежит.
4. Jitter обязательно.
5. Отбрасывать просроченное: если запрос пролежал дольше клиентского дедлайна, не обрабатывать его вообще — мощность освободится для актуальных.

Circuit breaker

Автомат из трёх состояний вокруг внешнего вызова: closed (считаем долю ошибок в скользящем окне), open (мгновенный отказ без обращения к зависимости), half-open (несколько пробных запросов; успех закрывает автомат, отказ снова открывает с увеличенной паузой). Ценен он быстрым отказом вместо медленного: освобождаются горутины и соединения, а упавшая зависимость получает шанс встать.

Тонкости, которые отличают знающего: считать долю, а не абсолютное число, и только при минимальном объёме в окне (иначе на низком трафике один сбой откроет breaker); таймауты считать ошибками, а бизнес-ошибки (404, 422) не считать; иметь fallback (кэш, дефолт, деградированный ответ), иначе выигрыш только в скорости отказа; отдельный breaker на каждую зависимость, а не один на сервис.

Bulkhead

Переборки из судостроения. На каждую зависимость или класс трафика заводят отдельный пул ресурсов: свой пул соединений, свой семафор на число одновременных вызовов, свой набор воркеров. Без них один медленный внешний API съедает все горутины — и падает весь сервис, включая ручки, которые к этому API не обращаются. В Go это чаще всего буферизованный канал как семафор плюс select с ctx.Done(), чтобы не ждать слот бесконечно.

Backpressure

Сигнал «притормози» вверх по потоку к источнику: TCP-окно, небуферизованный канал, ограниченная очередь, 429 с Retry-After, пауза в чтении из брокера. Очередь без границы работает не буфером, а отложенным отказом. Неограниченный канал превращает перегрузку в рост латентности и OOM вместо честного «не могу прямо сейчас».

Load shedding

Когда источник неуправляем (внешние пользователи), остаётся отбрасывать часть запросов, чтобы обслужить остальные. Отличие от rate limiting: rate limit задаёт политику по клиенту, shedding реагирует на своё состояние (длина очереди, использование CPU, возраст запросов в очереди). Отбрасывать правильно по приоритету (сначала фон и аналитика, платежи в последнюю очередь) и как можно раньше и дешевле, до похода в БД.

Проблема с числами

100 узлов кэша, 100 млн ключей. Добавляем 101-й: % 100 стало % 101, и на новое место переезжает доля N/(N+1) — около 99 % ключей. Весь кластер одновременно промахивается, трафик уходит в базу — база ложится. Инцидент устроила не авария, а плановое добавление мощности. С консистентным хешированием переезжает 1/(N+1), примерно 1 %, остальные 99 % ключей остаются на своих узлах.

Кольцо

Пространство хешей (0…2³²−1) замкнуто в кольцо. На него отображаются и узлы (по хешу имени), и ключи. Правило: ключ принадлежит первому узлу по часовой стрелке. Ищут бинарным поиском по отсортированному массиву позиций, O(log N).

• Добавление узла: он вклинивается между двумя существующими и забирает ключи только у одного соседа, той дуги, которая теперь заканчивается на нём.
• Удаление узла: вся его дуга целиком достаётся следующему по часовой стрелке. Именно здесь наивное кольцо опасно: сосед получает удвоенную нагрузку, падает следом — начинается каскад.

Виртуальные узлы

Каждый физический узел сажают на кольцо V раз под разными метками (hash("A#0"), hash("A#1"), …). Что это даёт:

1. Равномерность. Три случайные точки почти никогда не делят кольцо на три равные дуги, разброс в 2–3 раза тут обычное дело. При V = 100–200 разброс падает до единиц процентов.
2. Каскада не будет. При отказе узла его 150 дуг распределяются между всеми оставшимися, а не сваливаются на одного.
3. Взвешенность. Узлу с вдвое большей памятью даём вдвое больше виртуальных точек — разнородное железо загружается пропорционально.

Цена: V×N записей в памяти (100 узлов × 150 = 15 000, копейки) и чуть более долгий поиск.

Базовая реализация и её обязательные детали

SET lock:job42 <uuid> NX PX 30000     # NX = только если свободен, PX = TTL
# снимаем только свою блокировку, атомарно через Lua:
# if redis.call("get",KEYS[1]) == ARGV[1] then return redis.call("del",KEYS[1]) end

• TTL обязателен, иначе упавший держатель заблокирует ресурс навсегда.
• Уникальное значение обязательно, иначе процесс, чей TTL уже истёк, снимет блокировку, взятую другим.
• Продление (watchdog). Если работа может занять дольше TTL, фоновая горутина продлевает аренду; при неудачном продлении процесс обязан сам прекратить работу.

Фундаментальная проблема

P1 взял блокировку с TTL 30 с и застрял на 40 с — stop-the-world GC, своп, вытеснение, сетевая задержка. Блокировка истекла, P2 её взял и работает. P1 просыпается: с его точки зрения ничего не произошло, он «владеет» блокировкой и пишет в хранилище. Два процесса в критической секции. Никакой алгоритм блокировки этого не предотвратит, потому что нельзя остановить процесс, который считает себя владельцем, и нельзя узнать снаружи, что он застрял, а не умер.

Fencing token

Сервис блокировок выдаёт вместе с блокировкой монотонно возрастающий номер. Клиент передаёт его в защищаемый ресурс при каждой операции; ресурс помнит максимальный виденный номер и отвергает всё меньшее. P1 получил 33, P2 получил 34; после записи P2 запись P1 с номером 33 отвергается.

// UPDATE ... WHERE fence < $token: ресурс сам отсекает устаревшего владельца
res, _ := db.Exec(ctx,
    `UPDATE jobs SET result = $1, fence = $2 WHERE id = $3 AND fence < $2`,
    data, token, jobID)
if n, _ := res.RowsAffected(); n == 0 {
    return ErrStaleLockHolder
}

Отсюда вывод: если ресурс не умеет проверять токен (обычный S3-бакет, сторонний API, отправка письма), полной защиты не существует, и это надо честно признать, а не делать вид, что «Redlock всё решает».

Почему N/2+1

Два любых подмножества размера N/2+1 из одного множества обязательно имеют общий элемент. Этот общий узел не проголосует дважды в одном терме и не примет две разные записи на один индекс лога, поэтому split brain невозможен. Если бы кворумом была ровно половина, при разрыве 2/2 обе половины «набрали бы кворум» и выбрали разных лидеров.

Отсюда правило нечётного числа узлов. И отсюда понятно, почему кластер из трёх, потерявший два, перестаёт принимать запись, хотя один узел жив: он не может доказать, что он не в меньшинстве. Это и есть CP-выбор на практике. В Dynamo-подобных системах ту же идею записывают как W + R > N.

Raft по частям

• Терм нумерует эпохи монотонно; в терме не более одного лидера. Узел, увидевший больший терм, немедленно становится follower — так система вытесняет «зомби-лидера», вернувшегося после разрыва, без всякой ручной работы.
• Роли: follower, candidate, leader. Клиентские записи принимает только лидер.
• Выборы: у follower истёк случайный таймаут (150–300 мс) без heartbeat → term++, стал candidate, голосует за себя, рассылает RequestVote. Узел отдаёт голос, если ещё не голосовал в этом терме и лог кандидата не отстаёт от его собственного. Второе условие гарантирует, что лидером не станет тот, кто потерял закоммиченные записи.
• Split vote: несколько кандидатов стартовали одновременно, голоса разделились, большинства ни у кого нет. Терм проходит впустую, таймауты истекают, начинается следующий. Именно из-за этого таймаут случайный: рандомизация делает повторное совпадение маловероятным.
• Репликация лога: запись попадает в лог лидера → AppendEntries на followers → реплицирована на большинство → committed → применена к машине состояний → ответ клиенту. Отвечать клиенту до коммита нельзя: незакоммиченные записи при смене лидера могут быть отброшены.
• Свойство безопасности: закоммиченная запись присутствует в логах всех будущих лидеров. Следует это из правила голосования плюс пересечения кворумов.

Что из этого нужно прикладному разработчику

Не писать свой Raft, а уметь пользоваться готовым. Лидера для «одного cron на кластер» выбирают так: аренда в etcd/Consul, Lease в Kubernetes (тот же механизм, что у контроллеров), или строка в Postgres с TTL и FOR UPDATE. Обязательные детали: аренда продлевается в фоне; при неудачном продлении процесс сам складывает полномочия; вся защищаемая работа всё равно идемпотентна, потому что кратковременное перекрытие двух лидеров возможно по тем же причинам, что и нарушение распределённой блокировки.

Три семантики

• At-most-once: отправил и забыл, потери есть, дублей нет. Метрики, телеметрия.
• At-least-once: повторяем до подтверждения, потерь нет, дубли гарантированы. Это и дают на практике надёжные системы.
• Exactly-once как свойство сетевой доставки недостижимо (задача о двух генералах). Достижима effectively-once обработка.

Как делают на практике

1. Идемпотентный эффект бьёт всё остальное. UPSERT по естественному ключу, переход состояния с условием, запись в S3 по детерминированному имени. Дубли безвредны by design, хранить идентификаторы не нужно вообще.
2. Таблица inbox / processed. message_id PRIMARY KEY, INSERT ... ON CONFLICT DO NOTHING в одной транзакции с эффектом. Если отметку писать в Redis, а эффект в Postgres — вернулся dual write, и гарантия исчезла.
3. Окно дедупликации. Хранить идентификаторы вечно нельзя: окно выбирают (сутки, неделя) по максимально возможной задержке повтора; за его пределами дубль пройдёт. Это ограничение надо называть вслух.
4. Bloom-фильтр работает дешёвым предфильтром для больших потоков: «точно не видел» он отвечает мгновенно, «возможно видел» отправляет на точную проверку в БД. Ложноположительные срабатывания безопасны, ложноотрицательных не бывает.

Детали, которые проверяют

• event_id должен быть детерминированным. Если продюсер при каждой попытке отправки генерирует новый uuid.New(), дедупликация у потребителя не сработает никогда. Идентификатор рождается вместе с событием и не меняется при ретраях (в outbox это первичный ключ строки).
• Порядок коммита смещения. Коммит после обработки = at-least-once (упали до коммита — будет повтор); коммит до обработки = at-most-once (упали после — будет потеря). Правильный выбор почти всегда первый + идемпотентная обработка.
• Kafka EOS (enable.idempotence, транзакции, read_committed) закрывает схему consume–process–produce внутри Kafka: нет дублей при ретраях продюсера и атомарность «прочитал и записал». Но как только эффект уходит в твою БД, в письмо или во внешнее API, гарантия заканчивается и восстанавливается своими средствами.

Почему физическому времени нельзя верить

• Дрейф. Кварц уходит на 10–100 ppm, то есть на секунды в сутки.
• Скачки при коррекции. NTP может перевести часы назад — и два последовательных события получат метки в обратном порядке. Отдельно стоит високосная секунда — она исторически роняла целые кластеры.
• Погрешность синхронизации держится в единицах миллисекунд внутри ДЦ и в десятках между ДЦ. Это больше длительности многих операций, поэтому разрешение «до миллисекунды» между узлами остаётся иллюзией.
• В Go: для длительностей использовать монотонную составляющую (разность двух time.Now() корректна даже при переводе часов), а метки в данных читать как «примерно» и корректность на них не строить.

Happened-before и логические часы

Отношение → задают три правила: события внутри процесса упорядочены; отправка предшествует получению; отношение транзитивно. События, не связанные им, конкурентны, и это объективное свойство, а не незнание.

• Часы Лэмпорта. Счётчик на процесс; перед событием C++, при получении C = max(C, C_msg) + 1. Свойство: a → b влечёт C(a) < C(b). Обратное неверно: по номерам нельзя понять, были ли события конкурентными. Даёт полный порядок (ничьи разрешаются по id узла), но не обнаруживает конфликты.
• Векторные часы. Вектор из N счётчиков; при получении берут поэлементный максимум. Теперь конкурентность обнаруживается явно: если ни один вектор не меньше другого, это конфликт, и его можно отдать приложению (siblings в Dynamo/Riak) или разрешить структурой данных (CRDT). Платить приходится метаданными, они растут с числом узлов.
• Гибридные (HLC) комбинируют физическое время с логическим счётчиком: метки близки к реальному времени и при этом согласованы с причинностью. Используются в CockroachDB, YugabyteDB.
• В TrueTime у Spanner часы возвращают интервал с гарантированной границей ошибки, и коммит ждёт, пока интервал пройдёт. Настоящий порядок по времени покупается либо специальным железом, либо ожиданием.

Требования и расчёт

• Функционально: создать короткую ссылку (опционально свой алиас и TTL), перейти по ней, посмотреть статистику. Не делаем: аналитику в реальном времени, A/B, биллинг.
• Нефункционально: для чтения латентность p99 меньше 50 мс и доступность 99.99 % (редирект лежит на критичном пути), запись может быть медленнее.
• Цифры: 100 млн новых ссылок в месяц ≈ 40 записей/с; чтение к записи 100:1 → 4 000 чтений/с, пик ×4 ≈ 16 000 rps. Хранение: 500 Б на запись × 100 млн × 12 мес ≈ 600 ГБ/год — влезает в один сервер, шардинг пока не нужен. Горячие 10 % ссылок дают ~90 % трафика → кэш на 20–50 ГБ закрывает почти всё.

Генерация ключа: счётчик + base62 против хеша

Длина ключа: base62 (a–z, A–Z, 0–9) даёт 62⁷ ≈ 3.5·10¹² — семи символов хватит на десятилетия.

На практике берут счётчик, а его узкое место снимают так: не ходить в общий счётчик на каждую ссылку, а выдавать инстансам диапазоны (range allocator: сервис берёт блок из 10 000 идентификаторов одним INCRBY в Redis или UPDATE ... RETURNING в БД и раздаёт локально). Уходит и сетевой хоп, и единая точка отказа на горячем пути. Предсказуемость лечим перемешиванием битов перед кодированием (обратимая перестановка, Feistel-шифр на 41 бите: 2 в сорок второй уже больше, чем 62 в седьмой) — ключи остаются уникальными, но перестают идти подряд. Без общего счётчика можно обойтись и вовсе, взяв Snowflake-подобный id (время + id инстанса + последовательность).

Хранилище и кэш

• Модель тривиальна: short_key PRIMARY KEY, long_url, user_id, created_at, expires_at. Доступ строго по первичному ключу, идеальный кандидат для key-value, но Postgres на 600 ГБ и 40 записях/с справится без вопросов, и начинать стоит с него.
• Кэш: Redis, ключ → URL, TTL несколько часов, LRU. Хитрейт 90+ % за счёт распределения Ципфа. При промахе идём в БД и прогреваем кэш (single-flight, чтобы 1000 параллельных запросов на один холодный ключ не устроили stampede).
• Записи иммутабельны, и это сильно упрощает жизнь: нет инвалидации кэша, можно кэшировать сколь угодно агрессивно, можно раздавать через CDN.

301 или 302 — вопрос с подвохом

301 (Moved Permanently) кэшируется браузером надолго: следующий переход пойдёт мимо твоего сервиса. Меньше нагрузки, но ты теряешь статистику кликов и не можешь изменить или отозвать ссылку — браузер уже никогда не спросит. 302 (Found) не кэшируется: каждый переход приходит к тебе, статистика полная, ссылку можно отключить. Правильный ответ: 302 по умолчанию, потому что бизнес-ценность продукта держится на статистике и управлении ссылками; 301 остаётся опцией для тех, кому нужна максимальная скорость и не нужна аналитика. Отдельная тонкость: для редиректа корректнее 307/308, если важно сохранить метод и тело запроса, но для ссылок это несущественно.

Счётчики кликов

Инкремент строки в БД на каждый клик убивает сервис на первой же горячей ссылке. Правильный путь: редирект отвечает сразу, а событие клика уходит в брокер; отдельный потребитель агрегирует и пишет в аналитическое хранилище (ClickHouse) или инкрементит счётчик в Redis с периодическим сбросом в БД. Точность «примерно» здесь допустима, и это надо проговорить как осознанный выбор.

Требования

• Ограничивать по разным ключам: API-ключ, user_id, IP, эндпоинт, и по комбинациям. Разные лимиты для разных тарифов.
• Проверка должна укладываться в единицы миллисекунд, иначе лимитер сам станет узким местом.
• Точность: «примерно» приемлемо; распределённый лимитер, который гарантирует строгое «не более 100», требует согласования и стоит дороже, чем польза.
• Ответ при превышении: 429 плюс заголовки X-RateLimit-Limit, X-RateLimit-Remaining, X-RateLimit-Reset и Retry-After — без них клиенты будут долбить в цикле.

Алгоритмы

Практический выбор: token bucket, если хочется разрешать короткие всплески (нормальное поведение реальных клиентов), sliding window counter, если важна предсказуемость. Оба делаются в Redis двумя-тремя полями и Lua-скриптом.

# token bucket в Redis: атомарно через Lua (иначе гонка между GET и SET)
# KEYS[1] = bucket:user:42 ; ARGV = rate, capacity, now, cost
# HMGET tokens last_refill -> долить (now-last)*rate, обрезать по capacity
# если tokens >= cost: списать, вернуть 1 ; иначе вернуть 0 и время до пополнения
EVALSHA <sha> 1 bucket:user:42 10 100 1730000000 1

Архитектура

• Где принимается решение. На gateway/edge — как можно раньше, чтобы отброшенный запрос не тратил ресурсы. Отдельный «сервис лимитера» добавляет сетевой хоп и на горячем пути только вредит; лучше библиотека внутри gateway плюс общий Redis.
• Локальный слой + глобальный. Каждый инстанс держит локальный счётчик и синхронизируется с Redis не на каждом запросе, а пачками или по «квоте» (инстанс берёт из общего лимита долю и расходует локально). Сетевой вызов уходит из горячего пути ценой небольшой неточности.
• Хранилище. Redis (в идеале рядом, в том же регионе). Для мультирегиона держат лимиты по регионам, а не глобальный счётчик: кросс-региональная синхронизация на каждый запрос невозможна по латентности.
• Конфигурация лимитов меняется динамически, без релиза: правила в конфиг-сервисе с горячей перезагрузкой, потому что лимиты меняют чаще, чем код.

Расчёт, который определяет выбор

• 10 млн DAU, каждый заходит 10 раз в день → ~1 200 чтений ленты/с, пик ×4 ≈ 5 000.
• Постов: 1 млн в день → ~12 записей/с. Соотношение чтение/запись ≈ 100:1, значит, оптимизировать надо чтение.
• Средний подписчик: 200 фолловеров. При fanout on write один пост порождает 200 вставок → 12 × 200 = 2 400 вставок/с — вполне подъёмно.
• А теперь знаменитость с 50 млн подписчиков: один твит = 50 млн вставок. При 10 000 вставок/с это полтора часа на один пост, и всё это время часть подписчиков его не видит. Вот здесь чистый push и ломается.
• Хранение лент: 10 млн активных × 500 записей × 100 Б ≈ 500 ГБ в Redis — дорого, поэтому материализуют ленту только для активных пользователей (заходил за последние N дней) и ограничивают глубину.

Гибрид в деталях

1. Порог, скажем, 10 000 подписчиков. Ниже него работает fanout on write в Redis-список feed:{user_id} (обрезанный до 500–1000 записей, хранятся только id постов).
2. Выше порога не разносим вообще. При чтении: берём готовую ленту, отдельно читаем свежие посты тех знаменитостей, на кого подписан читатель (их обычно единицы-десятки и они прекрасно кэшируются), сливаем по времени/ранжированию.
3. Fanout выполняется асинхронно воркерами из очереди, публикация поста не ждёт разноса. Для активных подписчиков приоритет выше: те, кто онлайн, получают пост за секунды, остальные — за минуты.
4. Материализуем ленты только активных пользователей. Для вернувшегося через полгода лента собирается на лету и потом материализуется.

Дополнительные вопросы, которые почти всегда задают

• Удаление поста. Из миллионов лент его не вычищают, а фильтруют при чтении по «удалённым» (проверка id по множеству удалённых или по флагу в кэше постов).
• Ранжирование вместо хронологии. Тогда лента собирается из кандидатов и скоринга на чтении, и push вырождается в «список кандидатов», а не в готовую ленту.
• Согласованность. Лента eventual по определению: подписался — новые посты появятся, старые подтянутся отдельным процессом. Это нормально, и это надо назвать компромиссом, а не багом.
• Хранилище постов берут key-value или шардированное по post_id; ленты живут в Redis; связи подписок лежат отдельно, шардированные по follower_id для «на кого подписан» и по followee_id для «кто подписан» (две денормализованные таблицы, потому что нужны оба направления).

Транспорт

• WebSocket берут по умолчанию: двунаправленно, низкие накладные, работает через браузер. Альтернативы: SSE (только сервер→клиент, зато проще и переживает прокси), long polling (fallback), для мобильных — пуш-каналы (APNs/FCM), когда приложение в фоне и соединение держать нельзя.
• Слой соединений отдельный от бизнес-логики. Gateway держит сокеты и не знает домена; логика — в сервисах. Так логику можно деплоить, не рвя миллионы соединений.
• Реестр присутствия: user_id → gateway_id в Redis с TTL, обновляется heartbeat. Чтобы доставить сообщение, сервис смотрит реестр и шлёт на нужный gateway (напрямую или через топик/канал по gateway_id).
• Масштаб: одна Go-машина спокойно держит сотни тысяч соединений (~2–10 КБ на соединение при аккуратных буферах), так что 10 млн онлайна закрываются десятками узлов, а не тысячами. Узкое место обычно не CPU, а память под буферы и количество файловых дескрипторов.

Путь сообщения и подтверждения

1. Клиент отправляет сообщение с собственным client_msg_id (UUID), и это ключ идемпотентности: повтор после обрыва не создаст дубль.
2. Сервис сначала персистит сообщение и присваивает ему серверный порядковый номер seq в пределах диалога, потом отвечает отправителю ack: sent. Порядок «сохранить → подтвердить» принципиален: подтверждать до записи — значит терять сообщения при падении.
3. Дальше доставка получателям. Онлайн идёт через gateway, а для оффлайна сообщение просто лежит в истории, и клиент заберёт его при следующем подключении по своему last_seen_seq.
4. Получатель присылает delivered, при открытии чата — read. Оба статуса тоже сообщения, и они тоже могут потеряться, поэтому хранятся как «максимальный подтверждённый seq на пользователя», а не как флаг на каждом сообщении: так они идемпотентны и компактны.

Хранение истории

• Паттерн доступа один: «последние N сообщений чата» и «сообщения чата после seq». Это идеальный кандидат для wide-column хранилища: ключ партиции chat_id, кластеризация по seq DESC (Cassandra/ScyllaDB) или Postgres, шардированный по chat_id, с партиционированием по времени.
• Расчёт: 10 млн DAU × 50 сообщений/день = 500 млн сообщений/день × 300 Б ≈ 150 ГБ/день. Значит, нужны политика хранения (горячие последние месяцы, холодное — в дешёвое хранилище) и обязательное партиционирование по времени, чтобы удалять срезанием партиций, а не DELETE.
• Медиа не хранятся в БД: файл в S3, в сообщении — ссылка и метаданные.
• Групповые чаты: не копировать сообщение каждому участнику (fanout on write), а хранить один раз в чате и держать на пользователя только курсор прочитанного. Копирование оправдано только при малом размере групп и жёстком требовании к скорости чтения.

Онлайн-статусы

Самая недооценённая часть: наивное «рассылать всем контактам при каждом изменении» даёт квадратичный трафик. На практике: статус в Redis с коротким TTL, обновляемый heartbeat; рассылка изменений только тем, кто сейчас смотрит на этого пользователя (открыт чат или список); агрегация и throttling («не чаще раза в 10–30 секунд»); «был в сети недавно» с огрублением вместо точной секунды, что и дешевле, и приватнее.

Компоненты

1. Приём. API или подписка на события домена. Вход всегда несёт event_id для дедупликации и user_id.
2. Движок правил / preferences. Решает, каким каналам слать (push, email, SMS, in-app, webhook), и смотрит на подписки пользователя, отписки, язык, часовой пояс, тихие часы и глобальные настройки типа уведомления. Здесь же живут отписка и юридические требования: для email ссылка отписки обязательна.
3. Шаблонизатор. Отдельно от логики: текст, локализация, версии шаблонов. Шаблон в коде обернётся болью при первой же правке маркетологом.
4. Очереди по каналу и приоритету. Транзакционные («код подтверждения», «платёж не прошёл») идут в отдельную очередь с высоким приоритетом; маркетинговые в свою, и её можно тормозить или дропать при перегрузке.
5. Воркеры-адаптеры к провайдерам (APNs, FCM, SMTP/SES, SMS-агрегатор). У каждого свой пул (bulkhead), свой rate limit под квоту провайдера, свой circuit breaker.
6. Трекинг. Статусы: queued → sent → delivered → opened → failed, вебхуки от провайдеров, отдельная обработка «жёстких» отказов: по невалидному токену удаляем устройство, по bounce email помечаем адрес.

Надёжность и дедупликация

• Ретраи с экспонентой и jitter, разные политики по каналам: push дешёвый — можно повторять активно; SMS стоит денег, поэтому число попыток ограничено, а лимит расходов обязателен.
• Ключ дедупликации = (user_id, event_id, channel) в Redis/БД с TTL. Без него at-least-once доставка событий превращается в «пять одинаковых пушей подряд», и это самая заметная пользователю поломка.
• Дедупликация по смыслу, не только по id: «10 человек лайкнули ваш пост» сворачивается в одно уведомление в окне (например, 15 минут) вместо десяти пушей. Требование продуктовое, но живёт в этой же системе.
• Rate limit на пользователя: не больше N уведомлений в час независимо от того, сколько событий произошло. Защищает и пользователя, и репутацию отправителя.
• DLQ для окончательно неудавшихся: оттуда их можно разобрать и отправить заново.

Тихие часы и планирование

Тихие часы считаются в часовом поясе пользователя, а не сервера. На этом ошибаются постоянно. Внутри окна тихих часов уведомление не выбрасывается, а откладывается до открытия окна (это ровно задача планировщика отложенных задач из вопроса 9). Транзакционные и security-уведомления («вход с нового устройства») проходят всегда, и список исключений задаётся типом уведомления, а не отдельным флагом на каждом сообщении.

Отдельная тонкость масштаба: массовая рассылка на 10 млн пользователей не уходит одним залпом. Её разбивают на пачки и притормаживают (и по квоте провайдера, и по нагрузке на свои сервисы, потому что после пуша все эти люди одновременно откроют приложение, а вторичный пик на бэкенде часто больше, чем сама рассылка).

Загрузка

1. Клиент запрашивает POST /uploads с именем, размером, типом и (желательно) хешем содержимого.
2. Бэкенд проверяет права, квоту, лимит размера и допустимый тип, создаёт запись метаданных со статусом PENDING и выдаёт presigned URL с коротким TTL (минуты) и жёсткими условиями (максимальный размер, Content-Type, конкретный ключ объекта).
3. Клиент заливает напрямую в S3. Твои серверы не видят ни байта — это экономит трафик, память и снимает проблему «файл на 5 ГБ через Go-хендлер».
4. Подтверждают двумя способами: либо клиент дергает POST /uploads/{id}/complete, либо (надёжнее) бэкенд слушает событие от хранилища о появлении объекта. Второе устойчиво к тому, что клиент закрыл вкладку. Статус переходит в READY.
5. Фоном: антивирус, извлечение метаданных, превью и транскодирование. Всё через очередь, не в момент загрузки.
6. Уборка мусора: объекты, оставшиеся в PENDING дольше суток, удаляются (lifecycle policy в бакете + сверка с метаданными). Без этого хранилище копит недозагруженные файлы, за которые ты платишь.

Большие файлы: чанки

• Multipart upload: файл режется на части (обычно 5–100 МБ), каждая заливается по своему presigned URL, в конце вызывается complete со списком частей и их ETag.
• Что это даёт: возобновление после обрыва (перезалить одну часть, а не весь файл), параллельность (несколько частей одновременно, на длинных RTT это заметно быстрее), обход лимита на размер одного запроса.
• Клиент хранит состояние загрузки (какие части уже приняты), чтобы после перезапуска продолжить. Незавершённые multipart-загрузки тоже надо чистить политикой жизненного цикла, иначе за них капает счёт.

Дедупликация по хешу

Считаем SHA-256 содержимого (на клиенте, тогда можно вообще не заливать, или на сервере при обработке). Ключ объекта = хеш, метаданные ссылаются на него. Если файл с таким хешем уже есть, загрузка проходит мгновенно, место не тратится. Три обязательные оговорки: (1) нужен счётчик ссылок или отложенное удаление, иначе один пользователь удалит файл и сломает его у другого; (2) «мгновенная загрузка» по хешу без проверки владения открывает уязвимость: зная хеш, можно получить чужой файл, поэтому доступ проверяется по метаданным, а не по факту совпадения хеша; (3) для шифрованного на клиенте контента дедупликация не работает в принципе.

Раздача

• CDN перед хранилищем: файлы иммутабельны (ключ содержит хеш или версию), поэтому кэшируются вечно с Cache-Control: public, max-age=31536000, immutable. Обновление файла = новый ключ, а не инвалидация.
• Приватный контент раздаётся подписанными URL от CDN с коротким TTL и (для важного) привязкой к IP или подписью в куке. Не «секретная неугадываемая ссылка», если контент действительно приватный: такие ссылки утекают через реферер, мессенджеры и историю.
• Range-запросы для видео и докачки, ETag/If-None-Match для условных запросов.
• Стоимость: исходящий трафик обычно самая дорогая строка счёта. CDN берут ради скорости, но окупается он тем, что кэш-хит дешевле обращения к хранилищу.

Требования и расчёт

• p99 меньше 50–100 мс, иначе подсказки не успевают за печатью и бесполезны.
• Нагрузка обманчиво большая: 10 млн поисков в день × ~5 нажатий = 50 млн запросов в день ≈ 600 rps средних, пик ×5 ≈ 3 000. Debounce 100–150 мс на клиенте режет это в 2–3 раза бесплатно.
• Свежесть: для большинства запросов обновление раз в час-сутки нормально; для трендов («новость дня») нужен отдельный быстрый путь.

Структура данных

• Trie (префиксное дерево). Путь по дереву соответствует префиксу. Наивный вариант «дойти до узла и обойти всё поддерево» слишком медленный: у популярного префикса «а» миллионы листьев.
• Трюк, который и есть ответ: в каждом узле заранее хранится готовый топ-K (K = 5–10) завершений с их весами. Тогда запрос сводится к спуску по префиксу за O(len(prefix)) и возврату готового списка. Память растёт (K строк в каждом узле), зато чтение становится тривиальным.
• Сжатие: radix tree (объединение цепочек из одного потомка) уменьшает число узлов в разы; для очень больших словарей берут succinct-структуры или FST (так устроен Lucene).
• Где живёт: целиком в памяти сервиса, реплики читают одну и ту же иммутабельную версию. Альтернатива без trie: Redis sorted set на префикс (ZREVRANGE pfx:{prefix} 0 9) — проще в эксплуатации, но памяти больше и обновлять тяжелее.

Обновление

1. Логи запросов → агрегация за окно (час/сутки) в частоты → фильтрация (стоп-слова, мат, персональные данные, редкие «хвосты», запросы с нулевым результатом) → пересборка структуры.
2. Пересобирать целиком и подменять атомарно, а не мутировать на месте: новая версия trie строится офлайн, выкатывается на реплики, переключается указателем. Это снимает все проблемы блокировок и даёт мгновенный откат.
3. Веса считаются не по одной частоте: свежесть (экспоненциальное затухание старых периодов), персонализация и география ложатся отдельными слоями поверх базового топа, чтобы не пересобирать всё под каждого пользователя.
4. Тренды держат в отдельном маленьком «горячем» слое в Redis, который сливается с основным результатом на чтении. Свежесть появляется без пересборки основной структуры.

Кэш и клиент

• Кэш префиксов на стороне сервиса: короткие префиксы (1–3 символа) дают подавляющую долю запросов и почти не меняются, поэтому их ответы кэшируются с большим TTL. Распределение резко Ципфовское, и небольшой кэш даёт очень высокий хитрейт.
• На клиенте: debounce (не слать на каждый символ), отмена предыдущего запроса, локальный кэш уже полученных префиксов (пользователь набрал «моск», а ответ для «мос» у клиента уже есть, и он отфильтрует локально), плюс подстраховка от гонки: ответы приходят не в том порядке, и показывать надо только ответ на актуальный префикс.

Модель: платёж — конечный автомат

CREATE TABLE payments (
    id              uuid PRIMARY KEY,
    idempotency_key text        NOT NULL,
    user_id         bigint      NOT NULL,
    amount          bigint      NOT NULL,        -- только целые: копейки/центы
    currency        char(3)     NOT NULL,
    state           text        NOT NULL,        -- CREATED|AUTHORIZED|CAPTURED|FAILED|REFUNDED
    provider_ref    text,                        -- id операции на стороне провайдера
    version         int         NOT NULL DEFAULT 0,
    created_at      timestamptz NOT NULL DEFAULT now(),
    updated_at      timestamptz NOT NULL DEFAULT now(),
    UNIQUE (user_id, idempotency_key)            -- защита от двойного создания
);

Три вещи, которые надо сказать про модель. Деньги считаем целым числом в минимальных единицах: float для денег сразу поднимает красный флаг. Переходы только вперёд и только условные: UPDATE ... WHERE id=$1 AND state='CREATED' делает повторы идемпотентными. Двойная запись для баланса: серьёзные системы хранят не «баланс», а неизменяемый журнал проводок (ledger), где на каждую операцию приходится пара дебет/кредит, а баланс выводится из них. Тогда история восстановима и расхождения ловятся арифметикой.

Поток

1. Вход: POST /payments с Idempotency-Key. Повтор с тем же ключом возвращает тот же платёж, а не создаёт новый. Ключ и платёж создаются одной транзакцией.
2. Только вызов провайдера неидемпотентен изначально. Передаём провайдеру свой ключ идемпотентности (нормальные провайдеры это поддерживают), сохраняем provider_ref.
3. Неопределённость. Если ответ не пришёл, нельзя считать платёж неуспешным: он мог пройти. Состояние остаётся «в процессе», и стартует опрос статуса у провайдера по своему ключу, пока тот не ответит определённо. Здесь и видно разницу между продуманным дизайном и наивным.
4. Вебхуки от провайдера подтверждают операцию асинхронно. Обязательно: проверить подпись, дедуплицировать по id события, обработать идемпотентно и выдержать любой порядок (вебхук «captured» может прийти раньше, чем ответ на исходный запрос).
5. Outbox: смена состояния платежа и событие для остальной системы (payment.captured) пишутся одной транзакцией; релей публикует в брокер. Никаких прямых вызовов «сообщить сервису заказов» из транзакции.
6. Сага для составных сценариев («оплата + резерв товара + бонусы»): оркестратор с персистентным состоянием, компенсации (возврат оформляется новой операцией, а не откатом), необратимые шаги в конце.

Сверка (reconciliation) — обязательная часть, а не опция

Любая распределённая система рано или поздно расходится с внешним контуром. Ежедневный (а для крупных — ежечасный) процесс выгружает реестр операций провайдера и сравнивает с собственной базой по трём признакам: есть у нас — нет у них (мы считаем платёж успешным, а денег нет), есть у них — нет у нас (деньги списаны, а заказ не создан — самое опасное), суммы или статусы различаются. Расхождения попадают в отдельную очередь ручного разбора со своим SLA. Кто называет сверку без подсказки, тот с деньгами работал, а не читал про них.

Требования, от которых зависит выбор

• Точность: «примерно через час» (планировщик раз в минуту) или «ровно в 12:00:00.000» (таймер в памяти). Разница в стоимости на порядок.
• Горизонт: минуты, дни или годы вперёд (напоминания, подписки).
• Объём: тысячи задач или сотни миллионов «висящих» одновременно.
• Гарантии: at-least-once (норма) или дубли недопустимы; переживает ли задача рестарт; можно ли её отменить и перепланировать.
• Профиль: равномерно или пиками (всё на «ровно 9:00» случается очень часто и ломает наивные реализации).

Три подхода

Есть ещё готовые механизмы брокеров: delayed exchange в RabbitMQ, DLX с TTL, SQS DelaySeconds (до 15 минут), scheduled messages в Pulsar. Они удобны для коротких задержек и плохи для длинных горизонтов и для отмены — сообщение, уже лежащее в очереди с задержкой, обычно нельзя ни отменить, ни перепланировать.

Детали, за которые ставят плюс

• Claim с TTL, а не просто статус. Забирая задачу, воркер пишет claimed_until = now() + interval '5 min'; фоновый процесс возвращает в SCHEDULED всё, у чего срок истёк. Иначе упавший воркер забирает задачу с собой навсегда.
• Идемпотентность выполнения обязательна: гарантия at-least-once, и при неудачном подтверждении задача выполнится дважды.
• Ретраи с экспонентой и DLQ: неуспешная задача перепланируется на now() + backoff, после N попыток уходит в DLQ с алертом.
• Пик на круглое время. Все задачи на «ровно 9:00» создают всплеск, который положит и БД, и потребителей. Лечат это jitter при планировании (размазать по окну ±N минут, если бизнес позволяет) и ограничением скорости выдачи задач воркерам.
• Партиционирование по run_at: старые выполненные партиции отрезаются мгновенно вместо тяжёлого DELETE; индекс по run_at делают частичным, только по state='SCHEDULED', чтобы он оставался маленьким при миллиардах выполненных задач.
• Точность против масштаба, названная явно: опрос БД раз в секунду даёт точность ±1 с и нагрузку 1 запрос/с — для 99 % задач этого достаточно. Точность в миллисекунды требует таймеров в памяти и, значит, механизма восстановления после рестарта. Требовать точность выше необходимой значит заниматься оверинжинирингом, и про это стоит сказать вслух.

Правильная структура ответа

1. Сначала уточнить, x10 чего. Чтений, записей, объёма данных или числа пользователей? Это совершенно разные проблемы: x10 чтений лечится кэшем и репликами почти бесплатно, x10 записи упирается в шардинг или смену хранилища, x10 объёма — в партиционирование и архивацию.
2. Посмотреть на измерения, а не гадать. «Открою дашборд и посмотрю, где насыщение: CPU, диск, пул соединений, лаг очереди, лаг репликации». Ответ «сначала измерю» на этом вопросе всегда правильный.
3. Дальше по возрастанию стоимости:
   • Кэш и индексы обходятся дешевле всего. Один пропущенный индекс часто даёт те самые 10× без единой новой машины.
   • Вертикально: просто увеличить машину. Скучно, но до определённого размера дешевле любой переработки архитектуры, и зрелость как раз в том, чтобы это признать.
   • Горизонтально stateless-слой, то есть добавить реплик приложения за балансировщиком. Работает, только если приложение действительно stateless.
   • Реплики для чтения, обязательно с оговоркой про лаг и read-your-writes.
   • Вынести тяжёлое в асинхронный контур: всё, что не нужно клиенту для ответа, уезжает в очередь. Часто это даёт больше, чем новое железо.
   • Шардинг идёт последним и стоит дороже всего: выбор ключа, ребалансировка, кросс-шардовые запросы, распределённые транзакции. Назвать ключ и его недостатки обязательно.
4. Назвать, что не масштабируется: единственный лидер БД на запись; горячий ключ или горячая партиция; глобальный счётчик/последовательность; блокировки на популярной строке; внешний провайдер с жёсткой квотой; кросс-шардовые транзакции и джойны; всё, что требует глобального порядка.
5. Не забыть про деньги и эксплуатацию. x10 нагрузки превращается в x10 счёта, если ничего не оптимизировать. Иногда правильный ответ звучит как «сжать данные, удалить старое, поднять хитрейт кэша», а не «купить в 10 раз больше серверов».

Список кандидатов по частоте

1. База данных. Сначала не «падает», а деградирует: растёт время запросов, копятся блокировки, забивается пул соединений, растёт лаг репликации. Подкатегории: одна горячая строка (счётчик, баланс), длинные транзакции, отсутствующий индекс, автовакуум не успевает.
2. Пул соединений. Очень частый и неочевидный первый рубеж: приложение масштабируется горизонтально, каждый инстанс держит 50 соединений, на 20 инстансов выходит 1000, а БД держит 500. Дальше все ждут в очереди за соединением, и латентность взрывается при свободных CPU.
3. Кэш. Не сам Redis, а хитрейт: когда объём данных растёт, горячее множество перестаёт помещаться, хитрейт падает с 95 % до 80 %, и нагрузка на БД учетверяется при том же трафике. Самая коварная нелинейность в системе.
4. Внешние зависимости с квотой: платёжный провайдер, SMS-шлюз, геокодер. Их лимит не растёт вместе с тобой.
5. Диск. IOPS и место: логи, WAL, временные файлы сортировок. Кончилось место под WAL — БД встала целиком: классическая причина полной остановки.
6. Единственные по природе компоненты: лидер кластера, шедулер, воркер, который «почему-то один», глобальный счётчик.
7. Сеть и балансировщик: лимит соединений, полоса, число портов при NAT.

Как отвечать, чтобы это звучало как опыт

Не перечислять список, а разобрать свою схему: «в этой системе первым сдастся мастер БД: при 5 000 rps записи по 3 индексам на таблицу мы упрёмся в IOPS; увижу я это по росту p99 времени коммита и по длине очереди в пуле соединений; следом деградирует всё, что делит с ней пул, потому что таймауты начнут копить горутины». То есть: компонент → метрика → следствие.

Чек-лист по схеме