WebSocket, SSE, long и short polling на одном стенде с серверами на Go и Java за Angie и шиной Redis или NATS: сколько байт стоит событие, что прокси делает с длинным соединением, доходит ли событие до клиента на другом инстансе, что теряется при разрыве и почему буферизация прокси прячет от сервера медленного клиента. Всё — счётом исходов, без замеров задержки
Запустить Temporal легко, эксплуатировать — отдельная работа. Разбираем тюнинг воркеров (ёмкость, pollers, sticky cache) с замером, где расширение воркера сокращает ожидание задач почти в десять раз при неизменном сервере; наблюдаемость и два семейства метрик с похожими именами, которые нельзя путать; тестирование с промоткой времени — Sleep(24h) проходит за десятки миллисекунд; и выбор Cloud vs self-host с честной оценкой стоимости. Это статья про то, что отличает пилот от прода
Когда пайплайн собран, встаёт вопрос дисциплины релизов и того, как понять, что доставка вообще здоровая: semver и что версия обещает (и где он неуместен), автоматизация релизов и changelog из коммитов, релизы в монорепо, и актуальные пять метрик DORA — deployment frequency, change lead time, failed deployment recovery time, change fail rate, deployment rework rate — почему MTTR из прежних «четырёх ключей» переопределена, как читать метрики, не превращая в KPI-театр, и как они связаны с SLO и постмортемами
Деплой без простоя ломается не на коде, а на схеме: переименовал колонку — и старые поды падают. Expand-contract (сначала расширить схему, выкатить код, потом сузить), почему миграция и код едут в разном порядке, backward/forward-совместимость между версиями во время rollout, блокирующие DDL и как их избегать, безопасный rollback и роль feature flags. Как менять схему под работающим трафиком
Самая недооценённая дисциплина Temporal: нельзя просто поменять код workflow, у которого есть запущенные экземпляры — при replay новой логики на старой истории рантайм упрётся в non-determinism error. Разбираем, почему так, где именно проходит граница ломающего изменения (она не там, где кажется), как чинит patching/GetVersion и почему преждевременное снятие патча ломает всё заново. Плюс worker versioning с build IDs и то, как встроить версионирование в деплой до первого инцидента, а не после
Workflow не живёт в вакууме: снаружи в него шлют события (Signal), читают его состояние (Query), выполняют валидируемые мутации (Update), а сам он декомпозируется на дочерние (child workflows). Разбираем каждый механизм: Signal как асинхронное входящее событие и «человек в цикле», Query как чтение без изменения истории, Update как синхронная валидируемая команда, child workflows для декомпозиции и независимого версионирования, и Continue-As-New как способ жить с ограничением размера истории в долгих и циклических процессах
Весь I/O в Temporal живёт в activity — и именно на activity держится надёжность процесса. Разбираем четыре таймаута (ScheduleToStart, StartToClose, ScheduleToClose, Heartbeat) и что каждый ловит; retry-политики и non-retryable ошибки; heartbeat для долгих задач — и почему он возобновляет работу не с точки остановки, а с более ранней; почему идемпотентность activity целиком на вашей стороне (ретрай вызовет её повторно) и во что обходится её отсутствие; local activities и их цена в событиях истории. Это статья про то, что делает workflow надёжным, а не просто запущенным
Магия «код продолжается с той же строки» держится на одном жёстком требовании: workflow-код должен быть строго детерминированным. Разбираем, что это значит на практике — почему нельзя time.Now(), rand(), прямой I/O, обход map в случайном порядке и потоки; как event history и replay восстанавливают состояние; что такое non-determinism error и откуда он берётся; и какой инструментарий workflow (таймеры, селекторы, side effects, детерминированные версии времени и случайности) заменяет запрещённое
Temporal изнутри — это не «сервер», а четыре кооперирующихся сервиса (frontend, history, matching, worker) поверх persistence-хранилища и отдельного visibility-store. Разбираем, кто за что отвечает, как workflow шардируется по history-сервису, что физически лежит в PostgreSQL/Cassandra, зачем нужен отдельный visibility-store (Elasticsearch/Advanced Visibility) и как устроены task queues, на которых висят воркеры. Понимание этой механики — то, что отличает «запустил docker-compose» от «эксплуатирую в проде»
Прежде чем нырять в Temporal, стоит понять парадигму, которую он реализует: durable execution — выполнение, которое не теряется при падении процесса. Разбираем идею честно: что значит «код продолжается с той же строки после краха», как это даёт replay event history, откуда парадигма выросла (Cadence → Temporal) и чем durable execution отличается от очередей, saga-оркестраторов и BPM. Плюс ландшафт: Temporal, Cadence, Restate, DBOS, AWS Step Functions, Azure Durable Functions — кто на что и где граница применимости
