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

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

Строгая типизация в HurriCache — осознанный выбор. Мы явно создаём скаляры (целые числа, числа с плавающей точкой, байтовые массивы) и контейнеры (List, Vector, Queue, OrderedSet, HashSet, SortedMap, HashMap) без ленивого приведения типов. Это даёт предсказуемость поведения и контроль над памятью, но повышает порог входа: нельзя просто взять и «подставить» HurriCache вместо Redis, не меняя семантику работы с данными.

Чтобы решить эту проблему, мы добавили RESP‑коннектор, совместимый с Redis‑клиентами. И сразу столкнулись с фундаментальными различиями моделей данных: то, что в Redis «просто строка», в HurriCache требует явного типа и стратегии создания.

Для человека, впервые погружающегося в историю систем управления базами данных, последовательность SQL → NoSQL → NewSQL выглядит как диалектическая триада: тезис, антитезис, синтез. Сначала традиционные реляционные СУБД стали основой большинства коммерческих информационных систем, затем на волне NoSQL появились архитектуры, которые ради горизонтального масштабирования отказывались от части привычных реляционных ограничений и гарантий, и наконец направление NewSQL попыталось взять лучшее от обоих миров: SQL и ACID – от реляционных СУБД, горизонтальное масштабирование – от NoSQL.

Лет десять назад я делал инструмент сверки таблиц для мультимастера — крайне неэффективным способом: брал снапшот и под ним просто шёл по таблице, матчил строки. С тех пор задача стала только актуальнее: одни и те же данные всё чаще живут в разных дата-центрах, на разных инстансах с надёжным failover’ом, и рано или поздно приходится задумываться о проверке их идентичности.

Готовые инструменты для сравнения таблиц в мире Postgres есть — pg_comparator, pgCompare, ACE. Однако давайте сегодня поразмышляем, стоит ли ради большей эффективности городить огород с дополнительным софтом. Может быть, хватит простой транзакции и golang-скрипта, выполняющего SQL на обоих инстансах?

Redis у сервиса прогнозов не было восемь недель: контейнер упал с кодом 255 и больше не поднялся. Всё это время каждый запрос считался заново, 1,9 секунды вместо 11 миллисекунд. При этом авария не была тихой. В обработчике ошибки стоит self.redis_client = None с комментарием про заглушку, но заглушки там нет, поэтому каждый вызов get и set падал с AttributeError, ловился своим же except и писал ERROR в лог. Две строки на каждый запрос, восемь недель подряд. Разбираю, почему я этого не видел, почему health сервиса всё это время отдавал вписанное в код «ok» с таймстампом из мая 2025 года, и чем аккуратно обработанный отказ отличается от обычной поломки.

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

Привет! Меня зовут Сергей Прокопкин, я развиваю мотивационную программу и отвечаю за realtime-систему трекинга заданий в Авито. 

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

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

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

Давайте посмотрим на заголовки новостей за последние пару месяцев:

1. Побег из тестовой среды и атаки агентов OpenAI

В августе и октябре 2026 года стало известно о серьезных инцидентах с автономными ИИ-агентами от OpenAI. Выяснилось, что разработанные модели ИИ в ходе тестов на безопасность самостоятельно вышли в интернет через скрытые уязвимости, которые они сами же и обнаружили. 

Привет, Хабр! Меня зовут Иван Тарасов, я TUL Architecture Governance в техплатформе Авито. Одна из моих команд — SLA — создаёт условия для повышения технической надёжности, а также развивает инструменты NFR и сценарии стабильности.

В этой статье я расскажу, как в Авито устроена система измерения надёжности: от SLI/SLO/SLA и разницы между Stability Rate и Uptime, до устройства NFR для REST/RPC-сервисов, шин данных и кастомных операций.

Также поясню, чем концепция бюджета ошибок в Авито отличается от канонического описания в книге Google SRE, и почему это не случайное отклонение, а намеренное решение.

Остановил Python сервис с моделью машинного обучения, .NET API продолжил работать и вернул HTTP 503. После восстановления Python запрос снова завершился с HTTP 200, без перезапуска основного приложения.

Зачем разделять .NET и Python, как организовать взаимодействие между ними и что нужно предусмотреть, чтобы отказ ИИ оставался проблемой отдельной функции, а не всей платформы.

Ты не владеешь источником — значит, не владеешь временем. Как поллер по updated_at молча теряет строки, почему exactly-once это свойство твоей записи, и почему сверка важнее потока.

В данной статье рассмотрим сложные сценарии восстановления кластера Greengage DB, в которых кластер восстанавливается на новом окружении.

Привет, Хаброжители! Сегодня данные играют главенствующую роль в проектировании систем, и нужно обеспечить их масштабируемость, согласованность, надежность, производительность и удобство сопровождения. Необходимо учитывать огромное разнообразие систем хранения данных: реляционных баз данных, хранилищ NoSQL, складов и озер данных, а также облачных и локальных сервисов и встроенных баз данных.

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

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

Всем привет. На днях попалась информация интересная и захотелось разобраться в сервисе, которым пользуются миллионы людей – это Spotify.

На первый взгляд всё очень просто, нашли песню, нажали Play, музыка заиграла, но, если вспомнить, что за этим приложением стоят миллионы пользователей и миллионы треков, всё становится гораздо сложнее и интереснее.

Где физически лежит музыка? Почему один и тот же трек существует в нескольких версиях? Кто отправляет аудио пользователю? Почему Spotify не отдаёт весь файл через свой backend? Как музыка успевает загрузиться раньше, чем мы до неё дослушали? И откуда приложение знает, где мы остановились на другом устройстве?

Давайте разберёмся.

Рейт-лимит — это не ограничение скорости. Это бюджет, и тратишь его не ты один. Разбор на Telegram Bot API, Redis и одном наивном планировщике 2023 года.

Один ключ на все события заказа — и кажется, что порядок гарантирован. А потом клиенту приходит «Ваш заказ собран» раньше, чем «Оплата получена», витрина откатывает статус назад, а после планового перезапуска одно событие пропадает навсегда.

В статье разбираем три таких инцидента из одной системы на transactional outbox, PostgreSQL и Kafka 4.2. Попробуйте сами определить, где сломалось: в источнике, в relay, в продюсере или у потребителя.

Warpnet — это полностью децентрализованная, одноранговая социальная сеть, вдохновлённая Twitter, но построенная так, что у неё нет центральных серверов. Каждый пользователь запускает свой собственный узел (node), и именно эти узлы вместе образуют сеть.

Мы продолжаем рассказывать, как создавали AVM собственную платформу управления виртуальными машинами Aéza. В этой части разберём, как обновляем систему без остановки клиентских VM, выполняем живую миграцию, переживаем сбои и масштабируем инфраструктуру а также расскажем, с какими проблемами столкнулись по пути.

Привет, Хабр!

Мы считаем, что в настоящее время просто незаменимы книги, рассматривающие такие темы, которые пока не автоматизируются средствами искусственного интеллекта. Одна из таких предметных областей — проектирование распределённых систем. В нашем ассортименте давно закрепилась добротная книга Иэна Гортона «Масштабирование систем. Основы и проектирование распределённых архитектур», которую многие читатели сравнивают с «кабанчиком на минималках». Теперь же мы уже в начале октября ждём из типографии переведённую нами книгу «Think Distributed Systems», оригинал которой вышел в издательстве «Manning». Наш уважаемый автор Владислав Светлаков @svetlakoff, написавший книгу «Архитектура бэкенда. API для надежных корпоративных приложений», в своё время охарактеризовал книгу Торнова так:

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

Ниже мы перевели для вас обзор английской (аудио)версии книги «Think Distributed Systems» (вышла на русском языке в нашем издательстве под названием "Понятно о распределенных системах"), по которому предлагаем вам составить первое впечатление о ней.

Корпоративную GenAI платформу легко начать с выбора LLM, LangChain, vector database или Kubernetes. Но до этого полезнее ответить на другие вопросы: кто имеет доступ к данным, где проходит security boundary, какие компоненты действительно нужно разделять и что должно войти в первую версию.

В статье разберу, как спроектировать корпоративную GenAI платформу до начала реализации: требования и NFR, C4, Modular Monolith, разделение.NET и Python, PostgreSQL + pgvector, RabbitMQ, LLM Gateway, ADR и границы MVP.