Распределённые системы *

У меня было полторы сотни кросс-языковых фикстур, все тесты зелёные, и я был уверен, что мой Go-порт Yjs байт-в-байт совместим с оригиналом. Потом сравнил байты напрямую с канонической реализацией, и они разъехались: семантика сходится идеально, а на проводе документ толще.

Юнит-тесты, roundtrip и даже конвергенц-тесты систематически пропускают баги совместимости, когда портируешь чужой бинарный формат на другой язык. Рабочий метод один: генерировать фикстуры из канона и требовать в CI побайтового совпадения в обе стороны.

Разбираю конвейер и три реальных бага из трёх своих портов (Yjs, Loro, Willow): документ в 12 раз толще канона, big-endian остров, который молча портил бы все float’ы при обмене, и дыра, через которую 9-байтный апдейт заказывал make() на 67 ТБ. Метод обобщается на любой «порт формата X на язык Y», CRDT тут просто материал.

В задаче проектирования Rate Limiter важны сразу несколько вещей: выбор алгоритма лимитирования, централизованное хранение состояния, работа через API Gateway и масштабирование до 1 млн запросов в секунду. В статье разберём, почему для такого сценария часто выбирают Token Bucket, как использовать Redis для хранения счётчиков и что делать, когда одного инстанса уже недостаточно.

Девять AI-агентов делят одну API-квоту — и один ответ 429 быстро превращается в каскадный отказ всей системы. В этой статье разбираемся, почему стандартные ретраи и jitter перестают работать при общей квоте, и показывает архитектуру Rate Governor: с приоритетами, общим пулом токенов, предиктивным Circuit Breaker и координацией между агентами.

Третья, заключительная статья из цикла.

Часть 1 — где LLM теряет межсервисный контекст и почему локальных спек недостаточно.

Часть 2 — archspec как контракт вместо свободного Markdown.

Часть 3 — archspec investigate: исследование фичи, обновление контрактов и реализация.

В части 1 я показал, что spec-driven development с LLM начинает ошибаться, когда фича проходит через несколько микросервисов: по отдельности каждый сервис выглядит аккуратно, а вместе система работает не так, как нужно. Модель теряет межсервисный контекст — правила, которые живут на границах между сервисами, не записаны в одном месте, и LLM их пропускает. В части 2 я собрал archspec: на каждый сервис генерируется машиночитаемый контракт SERVICE_MAP.yaml, который делает эти правила явными.

В этой части я беру ту же фичу — автоматическое переназначение задачи после отказа фрилансера — и прогоняю её заново через /archspec:investigate, но уже поверх контрактов. Тот же промпт, та же модель (Claude Sonnet 4.6). Вопрос один: поймает ли план те межсервисные ошибки, на которых в первый раз фича не сошлась, ещё до написания кода — и где спотыкается уже сам инструмент.

Запись вернула ошибку, но значение всё равно оказалось в базе. Именно такие сбои Jepsen вытаскивает из распределённых систем: в статье разбираем реальный баг CockroachDB, путь от странного симптома до причины и то, почему на расследование ушло два месяца.

DLQ — это просто топик. Сложное — всё, что вокруг него.

Эта статья — про практическую архитектуру обработки событий из Kafka с отправкой данных во внешний REST API.

Главная проблема такого сценария — нестабильность внешнего API. Он периодически деградирует по latency или начинает отвечать с ошибками, и это напрямую влияет на пропускную способность всего консьюмера.

Долгое время главным критерием качества данных считалась их чистота и полнота. Компании инвестировали значительные ресурсы в MDM-системы и процессы проверки, стремясь получить «единую версию правды». Однако сегодня этого уже недостаточно. В условиях, когда скорость реакции определяет успех, на первый план выходит новый критерий — актуальность. Способность данных отражать реальное положение дел в момент принятия решения становится решающим фактором. При этом классические архитектуры, основанные на ночных загрузках в DWH, создают временной лаг, который превращает «правду» во «вчерашнюю». 

Привет, Хабр. Меня зовут Александр Шалудин. Я Presale-архитектор Data Services VK Tech. В этой статье я разберу, к чему может приводить работа с неактуальной информацией и как выстроить архитектуру, которая позволит устранить этот разрыв.

Из-за высокой конкуренции и сопутствующих вызовов многие компании стремятся стать Data-Driven, то есть принимать решения, основываясь на данных, чтобы сохранять конкурентоспособность, быстро реагировать на тренды и взвешенно оценивать бизнес-процессы.

Однако точность этих решений напрямую зависит не только от качества информации, но и от ее актуальности и доступности в нужный момент.

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

Большинство современных архитектурных подходов учат нас строить всё больше слоёв абстракции: контроллеры, сервисы, репозитории, адаптеры, транспортеры… Но что, если сложность системы растёт не из-за предметной области, а из-за самой архитектуры?

В этой статье я представляю FASA (Flat Adaptive Software ARchitecture) — спецификацию, которая предлагает радикально простой ответ: всего три сущности, строгие правила зависимостей и никаких промежуточных слоёв.

Вы узнаете, почему «плоский» граф компонентов может быть устойчивее многослойной архитектуры, как версионировать интерфейсы без боли, используя правило двойной поддержки (N-1) и где проходит граница между семантикой приложения и инфраструктурой — и почему это важно.

Спецификация языково-независима: примеры приведены для разных контекстов (Rust, сетевые протоколы, IPC), но правила применимы в любом стеке.

Иногда цифровая цивилизация ведёт себя как подросток, уверенный, что всё новое автоматически лучше старого. Облачные хранилища, распределённые бэкапы, георезервирование, «девять девяток» надёжности — всё это звучит внушительно ровно до того момента, пока кто-то не находит исходный код операционной системы… в гараже, аккуратно распечатанный на бумаге.

Мы убрали одну блокировку, чтобы апрувы перестали тормозить. Через несколько недель из‑за этого клиент пробил квартальный бюджет — а наша система этого даже не заметила.

Полгода после MVP, первые крупные клиенты. B2B travel SaaS, конец 2016-го. Компании начали подключать не по 15–20 человек, а по 80–100.

Один из новых клиентов оказался кратно крупнее остальных — финансовый департамент почти на сотню человек с фиксированным квартальным бюджетом на командировки порядка нескольких сотен тысяч рублей. К середине квартала большая часть бюджета уже потрачена, остаток — заметно меньше половины. Два руководителя — в разных городах, в разных браузерах — одновременно открывают форму апрува командировок. Оба видят один и тот же остаток. Один одобряет крупную поездку, другой почти в то же время — ещё одну, сопоставимую по сумме; каждая по отдельности в остаток вписывалась. Оба получают подтверждение. Вместе две поездки пробили лимит — перерасход, которого ни один из руководителей в одиночку не допускал.

Обнаружили через 3–4 часа — когда финансовый менеджер клиента открыл квартальную сводку и позвонил нам.

Почти все AI-проекты начинаются одинаково. Разработчик делает небольшой сервис с одним вызовом модели, подключает FastAPI, добавляет чат и показывает демо команде. На этом этапе всё выглядит настолько просто, что возникает опасное ощущение: «Ну это же обычный API-вызов, только ответ пишет нейросеть».

Вчера, если вы не в курсе, в стране отмечался Общероссийский день библиотек. Чем не повод отметить сие событие тематичной статьёй.

Она не стала великой сразу и не исчезла в один день. История Александрийской библиотеки — это длинный процесс, длившийся более шести веков: от амбициозного старта к постепенному усложнению и, в конечном счёте, распаду системы, которая удивительно напоминает раннюю версию того, что сегодня называют инфраструктурой хранения данных.

Всё началось с власти. Птолемеи, закрепившиеся в конце IV века до н.э. в Египте после распада державы Александра Македонского, строят Александрию как столицу нового типа — не только административную, но и культурную. Библиотека здесь возникает не просто ради собрания книг, а как политический проект: собрать тексты — значит собрать знание, а что знание — сила, понимали уже тогда.

Библиотека изначально была встроена в Мусейон — учреждение, которое Страбон в книге «География» описывает как часть царского дворца, где учёные живут, питаются и работают за счёт царя. Это был не архив, а научное производство: свитки не лежали мёртвым грузом, их читали, переписывали, сравнивали, исправляли.

Фактически библиотечных собраний было два: главное — в царском дворце в квартале Брухейон, и вспомогательное — в храме Сераписа (Серапеуме), где хранились общедоступные фонды и учебная литература.

В понедельник утром бухгалтер из клиентской компании написала мне в Telegram: «У контрагента в SAP всё оплачено, а в Smartup долг 12 миллионов». Я открыл обе системы. Одна и та же накладная. Два разных состояния. Два источника правды и оба врут.

Это было ровно то место в книге Designing Data-Intensive Applications, на котором я когда-то уверенно кивнул и пошёл дальше. Глава 5. Replication. «Ну да, master-slave, понятно». А когда через год сам построил систему с двумя ведущими даже не назвав её так, — Клеппманн взял своё со штрафами и пенями.

Это история о том, как я понял пятую главу DDIA не из книги, а из логов.

Всем привет! Меня зовут Миша, я разрабатываю платформу Яндекс Еды. В декабре я рассказывал, как Temporal без боли решает привычную проблему распределённой бизнес‑логики.

В продолжение темы я задумал написать такую статью, которую мне самому хотелось бы прочитать перед тем, как мы начали миграцию на Temporal. Всё изложенное проверено на практике: процессинг заказов Яндекс Еды уже почти год работает целиком на Temporal. Об общих принципах работы с Temporal я уже рассказал в предыдущей статье, а здесь я поделюсь полезными советами, выведенными из нашего опыта.

Некоторые части специфичны для разработки на Go, а другие вполне универсальны. Они организованы от общих к частным. Поделюсь практическими советами по архитектуре, тестированию, детерминизму и безопасному развитию Workflow. Покажу, как организованы миграции и эксплуатации в крупном продакшене.

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

Если совсем коротко напомнить, где мы остановились во второй части, то картинка такая. Гибридная архитектура из трёх слоёв: ECS-миры снизу как операционный движок для большого количества однотипных сущностей, акторы-менеджеры посередине как тактический уровень, и более тяжёлые акторы или сервисы наверху как стратегический мозг. Сбоку реактивная среда, которая подбрасывает события. Под всем этим слой данных на DuckDB. Технологически: Bevy ECS на Rust для движка, лёгкая акторная абстракция поверх, egui для дев-интерфейса, WASM для демонстраций в браузере, Godot 4 опционально как 3D-витрина. Этот расклад мне показался самым интересным, и в этой части я попытаюсь показать, к чему он прикладывается на практике.

Случай, произошедший со стартапом PocketOS, выглядел бы комичным, если бы не обернулся реальной катастрофой. ИИ-агент Cursor, работавший на базе Claude Opus, за девять секунд уничтожил не только основную базу данных компании, но и все резервные копии.

Продолжение истории. Во второй части речь пойдет про поиск пути к своему симулятору: затронем мультиагентные системы "прошлого" (MAS), акторную модель (actor model), современную игровую архитектуру ECS и Data-Oriented Design. Что взлетело, что не взлетело, и почему гибридная архитектура показалась подходящей для трёхуровневой модели управления из первой части. Все это с историческими отсылками к Хьюитту, Армстронгу и Эктону.

Современная розница уже не делится на «магазин» и «онлайн». Покупатель приходит в торговый зал, выбирает товар через мобильное приложение, оплачивает у кассы, забирает заказ из пункта выдачи и возвращает покупку курьером. Все эти сценарии опираются на одну ИТ-инфраструктуру: учётную систему, кассовый софт, сервисы лояльности и склада. Если хотя бы одно звено становится недоступным — останавливается не отдельный канал, а весь бизнес. Поэтому требование «работать 24/7» давно перестало быть лозунгом и превратилось в архитектурную задачу.

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

На первый взгляд кажется, что достаточно найти соответствующие сообщения и удалить их из Kafka topic. Но Kafka хранит данные как commit log, поэтому точечное удаление сообщений по версии таксономии или другому бизнес-признаку оказывается небезопасным.

В статье рассмотрим, почему прямое удаление сообщений не подошло, какие варианты были рассмотрены и как в итоге был применён комбинированный подход: стабильный Kafka key, tombstone-сообщения, compact/delete policy и проверка состояния таксономии на стороне consumer.

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

В предыдущей статье мы разобрали, как коботы и модульные рабочие ячейки решают проблему high-mix, low-volume производства. В частности говорилось о стандарте O-PAS. Попробуем раскрыть подробнее эту критическую часть: как управлять HMLV с программной стороны?