Нюансы проектирования распределенных систем
В статье рассматривается исполнительная часть утилиты ggrebalance: механизм физического перемещения primary- и mirror-сегментов между хостами кластера Greengage DB (open-source форк Greenplum), устройство конечного автомата ребаланса, отслеживание статусов операций, обработка сбоев и реентерабельность, откат перемещений, а также практические рекомендации по эксплуатации и итоговое сравнение с альтернативными инструментами.
Фискальный накопитель печатает чек — и связь обрывается до того, как пришёл ответ. Напечатался он или нет, узнать неоткуда: обе ситуации выглядят для сервиса одинаково. Повторить вслепую — риск юридически значимого дубля, не повторять — продажа без чека. Разбираю, как это решалось в облачной фискализации на сотни миллионов чеков в сутки: отдельное состояние «результат неизвестен», сверка с архивом накопителя по собственному идентификатору в реквизите чека, блокировка слота вместо продолжения наугад — и почему за корректность пришлось заплатить отказом от жёсткой временной гарантии. Первая часть из шести.
Для проверки сквозного трейсинга GenAI-приложения мы взяли OpenTelemetry Demo 3.0. В обновлённом стенде уже были сервисы chatbot, agentи mcp, а также ИИ-спаны. Оставалось направить телеметрию по OTLP в ProtoOBP и открыть готовую цепочку вызовов. Но все спаны приехали, а единой истории не получилось: один пользовательский запрос распался на два трейса на границе MCP.
Автоматическая HTTP-инструментация связь не восстановила. Мы проследили traceparent до MCP _meta, нашли место потери контекста и добавили небольшой слой над ClientSession. После исправления цепочка собралась в единый трейс из 27 спанов.
В статье покажем исходный разрыв, код исправления и проверку результата по клиентскому и серверному спанам и карте связей.
Спросите себя, что было результатом расследования сбоя десять лет назад, пять, год. Ответ будет примерно одинаковый – скриншот графика в рабочем чате и фраза «похоже, это база». Давайте посмотрим, что поменялось в 2026-м и как выглядит разбор аварии с помощью ИИ-агента.
От проблем PostgreSQL к скорости ClickHouse. Рассказываем, как переработали архитектуру кеширования для AI-тестов, чтобы выполнять более 2 млн запросов и обрабатывать 20 млрд записей в день, сохранив среднюю задержку поиска элементов на уровне 250 мс.
В дискуссиях о событийно-ориентированных системах часто разгораются жаркие споры об упорядочивании событий. Есть опасения, что, если события будут приходить в неверной последовательности, то нижестоящие системы могут развалиться, либо в них будут храниться несогласованные данные. При таком взгляде на вещи разработчики приходят к переусложнению продьюсеров, вынуждены требовать, чтобы события шли в строгом порядке или даже выбирают такие сервисы как топики SNS FIFO исключительно для соблюдения этих гарантий.
Но вот какова правда: для корректной работы продьюсеров в событийно-ориентированной системе не обязательно упорядочивать события. Действительно не обойтись без свойств, обеспечивающих правильный контекст — такой информации, как номера версий, метки времени updatedAt и идентификаторы объектов, по которой потребители могут самостоятельно судить о свежести и согласованности событий.
Ну вот оно и свершилось. Спустя 15 лет, и на 10 лет позже после мировых лидеров, наши чиновники родили не то сына, не то дочь, не мышонка, не лягушку, а неведому зверюшку. Иначе говоря - законом о цифровых валютах.
Сейчас мы вместе будем вгрызаться во внутренности этого диджитал Франкенштейна, порождением жадности, лоббирования, глупости и страха потери контроля.
Документ имеет внушительные 287 забористо написанного текста, написанного на чиновничьем языке, который неподготовленный человек не разберет. Слава богу есть ИИ, которые умеют переводить на человеческий, и энтузиасты-мазохисты типа меня, которые готовы этот перевод осуществить.
Чтобы жизнь медом не казалась, а может потому, что писать законы чиновники умеют примерно так же, как и компрессировать файлы, а может просто чтобы внушительнее выглядело, исходный документ имеет размер 153 мегабайта. После компрессии, документ превратился в скромные, совсем неположенные размаху законотворцев 34 мегабайта.
Есть вопросы, которые кажутся принадлежащими разным мирам. «Должен ли квадрат наследовать прямоугольнику?» — вопрос инженера за обедом. «Реальны ли универсалии или существуют лишь единичные вещи?» — вопрос, из-за которого в средневековых университетах ломали карьеры. Тезис статьи в том, что это один и тот же вопрос, и что программист, выбирая между интерфейсом и абстрактным классом, между наследованием и композицией, между актором и разделяемой памятью, совершает — обычно не подозревая — акт метафизического выбора, за которым стоят две с половиной тысячи лет спора.
В статье рассматривается планирование ребаланса кластера Greengage DB (open-source fork Greenplum) после shrink, декомиссии и добавления хостов: формальная модель размещения primary- и mirror-сегментов, минимизация числа перемещений, сравнение точных и эвристических алгоритмов и реализация планировщика в ggrebalance
Редкий сбой в распределённой системе может месяцами ускользать от команды, а при попытке воспроизведения исчезать из‑за изменившегося порядка событий.
В статье разберём, как deterministic simulation testing помогает управлять временем, сетью и отказами, воспроизводить сложные сценарии по seed и проверять системные инварианты на примерах FoundationDB и TigerBeetle.
Kafka часто появляется на System Design интервью, когда нужно асинхронно обрабатывать события и масштабировать систему.
Но за словами “добавим Kafka” скрывается много важных деталей: как выбрать ключ, сохранить порядок сообщений, распределить разделы между потребителями и не создать горячий раздел. В статье рассмотрим архитектуру Kafka, репликацию, смещения, повторные попытки и политики хранения.
Про Kafka в этой серии уже было. Теперь — RabbitMQ, и с упором на то, как им пользоваться. Коннектор redb.Route.RabbitMQ — поверх официального RabbitMQ.Client 7.x, но писать вам придётся не «клиент», а маршруты, где весь брокер задаётся одной строкой-URI:
Привет! На связи Влад, разработчик product-facade — сердца витрины Ozon и одного из самых высоконагруженных сервисов, который выдерживает до 2,2 млн RPS. В прошлой моей статье я рассказывал об одном из архитектурных вызовов, с которым мы столкнулись в процессе работы. В этот раз продолжим тему микросервисной архитектуры и поговорим о том, что происходит, когда привычная строгость контрактов начинает мешать.
Одна из ключевых причин использования gRPC для связи между сервисами — строгий protobuf-контракт. Он даёт типизацию, фиксирует схему данных и снижает риск случайно сломать интеграцию. Но иногда случаются ситуации, когда эти плюсы загоняют нас в рамки. Например, когда сервис просто передаёт данные дальше, но его всё равно приходится обновлять из-за изменений, которые нужны только конечному потребителю. В таких случаях полезно знать, какие механизмы protobuf позволяют работать с контрактом более гибко, не отказываясь от него полностью. В статье расскажу о трёх из них и приведу примеры, для чего они могут применяться.
На старте поисковая система часто устроена просто: одна таблица на одном сервере. Это работает, пока не случится одно из двух. Либо отдельный запрос перестаёт задействовать весь 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 для хранения счётчиков и что делать, когда одного инстанса уже недостаточно.