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

Долгое время главным критерием качества данных считалась их чистота и полнота. Компании инвестировали значительные ресурсы в 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 с программной стороны?

Сегодня много говорят об автоматизации в том ключе, что высокоскоростная робототехника хороша для массового производства одного типа продукта, и совершенно непригодна для гибкой переналадки. Между тем, модель производства, характеризующаяся широкой номенклатурой изделий при малых объемах выпуска (HMLV, high-mix low-volume) представляет значительный рынок.

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

ИСТОЧНИК ФОТО: концерн «Калашников».

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

Идемпотентность в System Design: полный пример

Идемпотентность часто упоминается при проектировании систем (system design). Ниже будет простыми словами объяснено, что это такое, далее мы разберём основные детали идемпотентности, часто понимаемые неверно и, наконец, проиллюстрируем её на полном примере. 

Что такое идемпотентность?

Операция является идемпотентной, если при однократном или многократном выполнении она всякий раз даёт один и тот же результат.

Я работаю в большой продуктовой компании с тысячей микросервисов. В такой системе даже небольшая фича часто проходит через несколько сервисов, событий и внутренних контрактов. Spec-driven development с LLM уже применяется в некоторых командах для планирования и ревью фич, поэтому мне было важно понять, где этот подход помогает, а где начинает ошибаться. Пока задача живёт внутри одного сервиса, всё обычно идёт быстро: спека короткая, описание и реализация помещаются в контекст модели. Но как только фича проходит через несколько сервисов, начинаются проблемы. По отдельности каждый кусок выглядит нормально: разбиение на слои, именование по код стайлу, прохождение тестов и ревью. Но в целом система не работает должным образом. Типичные ошибки: нет идемпотентности, LLM упускает сценарии и edge case-ы, появляются циклические вызовы сервисов. Чем больше делаешь правок, тем больше ошибок она допускает.

Для эксперимента я собрал отдельный стенд: Go-проект - платформа для поиска фрилансеров. Внутри 12 микросервисов, связанных через gRPC и брокер сообщений; в этом проекте брокером выступает NATS. Одни сервисы хранят задачи и профили исполнителей, другие подбирают кандидатов, считают расстояния, проверяют портфолио и отправляют уведомления. Проект специально спроектирован с шестью категориями архитектурных ловушек: они проявляются не внутри одного сервиса, а на границах между сервисами.

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

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

На это можно ответить, что нужен end-to-end тест на весь сценарий, но это не закрывает проблему целиком. End-to-end тесты есть не везде, их дорого поддерживать, и они не покрывают все развилки: особенно редкие edge case-ы, дубликаты событий, гонки и редкие комбинации условий. Главное же в другом: на этапе spec-driven разработки модель должна помочь собрать требования, ограничения и контекст, а именно там она часто ошибается.

Разработчик тоже не всегда заранее знает, где спрятана проблема. Он может помнить про Outbox, дедупликацию уведомлений или особые требования конкретного сервиса к входным данным, но не сформулировать это как ограничение для новой фичи. LLM читает документы по сервисам, задаёт уточняющие вопросы и всё равно может пропустить связь между ними.

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

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

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

Меня зовут Александр Гришин, я руковожу направлением хранения и обработки данных в Selectel. Отвечаю за развитие облачных баз данных, S3-хранилища, аппаратных СХД и сервисов для построения DLH. Материал будет полезен CTO, CIO и архитекторам, которые выбирают или проектируют собственное S3-совместимое хранилище. Или инженерам которые хотят просто лучше понимать, что же происходит у нашего сервиса под капотом.

У команды MyBox из Мастерской прошел тест-драйв гипотезы: можно ли сделать воспроизводимый продукт (наш MyBox) на Apple-железе так, чтобы удалённый узел мог криптографически проверить, что перед ним «правильный» продукт, а не подмена с применением админского доступа.

Спойлер: через хэш бинарника не проверяется, это решение отмели на краудсорсинге, а вот предложенное клонирование через ABM/MDM работает, но не элегантно. Вышло скорее размножение через центр, чем красивое p2p‑клонирование.

В конце — ограничения (в том числе про Россию) и почему мы продолжаем считать этот маршрут практичным для PoC/MVP. В комментариях оставили ссылку на разбор других (менее удачных) решений.