Нюансы проектирования распределенных систем
На входе у нас вакансия, на выходе — проверенный контакт в одной из трёх кампаний. Между ними: дубли, таймауты, catch-all, неоднозначные SMTP-ответы и окно, в котором процесс может упасть после передачи контакта, но до сохранения статуса. Показываю, как мы расставили дешёвые и дорогие проверки и почему выбрали at-least-once.
Есть класс ошибок, которые невозможно найти простой сверкой. Не потому, что данные хорошо спрятаны, а потому, что искомого состояния нет ни в одной системе. Оно собирается на лету из двух правильных половинок, каждая из которых по отдельности абсолютно валидна.
Хочу рассказать про случай, где в одном стартапе мы искали причину две недели, но при этом мониторинг всё это время показывал, что всё в порядке, и формально он был прав.
Распределенная система может сломаться так, что по отдельности все ее части будут выглядеть исправными.
Представим обычную оплату заказа: сервис отправил запрос платежному провайдеру, тот списал деньги и вернул успешный ответ. На обратном пути соединение оборвалось. Для платежной системы операция завершена, а сервис заказа получил тайм-аут и не знает, произошло списание или нет.
Самое очевидное решение — повторить запрос. И получить второе списание.
В монолите подобные ситуации встречаются реже: операция обычно проходит внутри одного процесса или одной транзакции, поэтому место сбоя проще определить. В распределенной системе между началом и концом одной бизнес-операции могут быть несколько сервисов, брокер сообщений, разные базы данных и внешний API (интерфейс программирования приложений). У каждого компонента при этом свое состояние и свое представление о том, что уже произошло.
Так, проверки «отправили запрос — получили ожидаемый ответ» здесь недостаточно. Интереснее проверить, что будет, если ответ задержится или потеряется, запрос придет повторно, события поменяются местами, а один из сервисов восстановится после нескольких минут простоя.
В таких ситуациях проявляются ошибки, которые сложно увидеть на happy path (позитивном сценарии). Ниже разберем, как их воспроизводить и что проверять, чтобы отказ одного компонента не превращался в некорректное состояние всей системы.
Почему распределенную систему нельзя тестировать как обычное приложение
Возьмем простой пример — оплату заказа в интернет-магазине.
Привет, Хаброжители! Язык Go востребован в разработке облачных сервисов и распределенных систем благодаря простоте, высокой производительности и встроенной поддержке конкурентности. Книга выходит за рамки синтаксиса и фокусируется на проектировании гибких и масштабируемых архитектур.
Вы сразу приступите к созданию проекта, который будет постепенно изменяться и усложняться от простых скриптов до полноценного клиент-серверного приложения. В процессе работы вы познакомитесь с конкурентным программированием с использованием горутин, работой с SQLite, написанием тестов, обработкой ошибок, работой с файловой системой, а также с объектно-ориентированным подходом.
В статье рассматривается исполнительная часть утилиты 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 и какой выигрыш по времени дают копирование файлов и режим жестких ссылок.