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

На старте поисковая система часто устроена просто: одна таблица на одном сервере. Это работает, пока не случится одно из двух. Либо отдельный запрос перестаёт задействовать весь CPU, за который вы заплатили, либо одного сервера перестаёт хватать — по объёму, по пропускной способности или просто потому, что сервер может выйти из строя, и данные на нём будут потеряны.

Автоматический шардинг, встроенный в Manticore Search и доступный начиная с релиза 27.1.5 , решает обе проблемы, разбивая таблицу на несколько физических фрагментов меньшего размера (шардов), по которым можно выполнять поиск параллельно и которые можно размещать на разных узлах:

Добрый день,Хаброжители! Сегодня мы подготовили для вас перевод статьи.

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

Вдохновляясь принципами языка Erlang, они представляют библиотеку ramure, которая позволяет легко создавать и оркестровать надежные агентные процессы с прозрачным мониторингом и механизмами восстановления.

Разбираем мажорное обновление Greengage с версии 6 на 7: как работает pg_upgrade, какие шаги нужны для обновления кластера, чем помогает ggupgrade и какой выигрыш по времени дают копирование файлов и режим жестких ссылок.

В статье рассматривается shrink кластера Greengage DB с использованием ggrebalance: архитектура утилиты, FSM-подход, безопасное перераспределение данных через INSERT, сравнение с CTAS, поддержка rollback и результаты тестов производительности.

Если ваш сервис одновременно пишет в БД и дёргает внешние API, прямо сейчас у вас есть как минимум один из этих сценариев:

– деньги списаны, заказа в базе нет;
– товар на складе заблокирован навсегда под «призрачный» заказ;
– курьерская служба везёт посылку, которую никто не заказывал.

Это не баги в коде – это архитектурная проблема двойной записи. И у неё есть классическое решение: паттерны Transactional Outbox, Result Table и Saga Compensation. Под катом – не только теория, но и живой рабочий проект на Scala, который можно склонировать и запустить.

У меня было полторы сотни кросс-языковых фикстур, все тесты зелёные, и я был уверен, что мой 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, то есть принимать решения, основываясь на данных, чтобы сохранять конкурентоспособность, быстро реагировать на тренды и взвешенно оценивать бизнес-процессы.

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

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

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

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

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

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

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

В понедельник утром бухгалтер из клиентской компании написала мне в 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-витрина. Этот расклад мне показался самым интересным, и в этой части я попытаюсь показать, к чему он прикладывается на практике.

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

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

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

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

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