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

Асинхронная клиент-серверная библиотека для обмена сообщениями между микросервисами на базе ZeroMQ. Реализует гарантированную доставку сообщений (At-Least-Once) с персистентной файловой очередью при обрывах связи, автоматический failover сервера переадресации (клиенты могут подхватывать роль сервера на лету) и два уровня защиты: шифрование канала (CurveZMQ) и сквозное шифрование сообщений (HMAC). Лёгкая альтернатива брокерам вроде RabbitMQ, не требующая отдельного сервера.

Расскажу про четыре production‑инцидента на одном куске кода за десять дней. В каждом я думал, что разобрался. Закончилось тем, что я выкинул pg_advisory_lock из retry‑пути и поставил FOR UPDATE SKIP LOCKED. Day‑generation лок остался advisory‑ным, но утечка там не критична — почему именно, разберу в конце. Полезно, если у вас Postgres на Neon (или Supabase, или Aiven serverless) и где‑то по коду есть session‑scoped advisory locks для координации задач между репликами.

Кажется, что время — это просто. Но мы, инженеры, теряем сон из-за такой простой задачи, как синхронизация часов.

Причина этого в том, что не существует каких-то глобальных часов. У нас есть тысячи машин, распределённых по дата-центрам, континентам и часовым поясам; каждая из них работает независимо от других, поэтому ответ на простой вопрос «сколько сейчас времени?» оказывается на удивление сложным.

Синхронизация часов становится основой самых сложных задач в распределённых системах, она влияет на всё, от согласованности баз данных и отладки до финансовых транзакций.

Tinder — это хороший пример system design задачи, где нужно быстро формировать ленту кандидатов, учитывать геолокацию и пользовательские предпочтения, а также надёжно обрабатывать свайпы и совпадения. В статье разберём архитектуру такого сервиса и узкие места, которые появляются при росте нагрузки.

Как обучить ML-модели на Edge-устройствах с памятью <256 МБ? Привет, Хабр! Я — Александр Лошкарев, инженер-программист, и это вторая часть материала о федеративном обучении. В первой мы рассматривали, зачем в принципе понадобилось добавлять устройствам интеллект, о преимуществах FL, архитектурных подходах и вызовах.

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

Если ваше устройство думает, что 1 ГБ — это ругательное слово, то этот доклад в двух частях для вас.

Меня зовут Александр Лошкарев, я инженер-программист в компании Eltex. Этот материал основан на моем докладе для AiConf и посвящен федеративному обучению (FL). Мы разберем, как внедрять ML-модели на краевых устройствах, которые жестко ограничены в ресурсах и имеют меньше 256 МБ оперативной памяти. 

Умные колонки, ТВ, камеры и другие устройства с ИИ-ассистентом сегодня — это уже не просто бытовая электроника повседневной жизни. С точки зрения безопасности это распределённая система, в которой граница доверия проходит через несколько уровней — от аппаратных механизмов до серверной логики, поэтому и подход к защите должен быть разносторонний.

Меня зовут Никита, и мне как инженеру по информационной безопасности Алисы и Умных Устройств Яндекса приходится быть по обе стороны баррикад: думать, как сделать устройства безопасными и знать, как их «ломать». Всегда нужно рассматривать потенциальные векторы атак и способы защиты от них. В этом во многом помогает наша программа «Охота за ошибками». А сегодня я расскажу о том, как смотреть на смарт-девайсы с точки зрения информационной безопасности, какие есть реальные риски и как их минимизировать.

В 09:00 по Москве кто-то в команде уже закрывает первую задачу, а кто-то только входит в рабочий ритм. В инфраструктурных проектах это либо превращается в бесконечные «созвоны ради созвонов», либо дает реальное преимущество по скорости и качеству. Меня зовут Виталий Попов, в «Софтлайн Решения» я отвечаю за реализацию инфраструктурных проектов. И мы пошли по второму пути — и это не про героизм, а про инженерную настройку процесса и нормальные человеческие границы.

Вы слышали о Kafka, MQTT, S3, Iceberg, Trino, PostgreSQL, Redis и Flink? А насколько хорошо вы знаете эти технологии? По каждой из них написаны огромные книги («Kafka: The Definitive Guide», около 800 страниц), и каждый день выходят новые публикации про тонкости.

Эта статья про другое.

Вместо внутренностей движков и законов распределённых систем посмотрим на эти технологии как на кубики LEGO: какую роль каждая из них играет в архитектуре и как они стыкуются друг с другом. Это будет практический туториал: начнём с минимальной конфигурации и постепенно соберём сложную систему. Статью можно просто читать как обзор архитектуры, а можно запускать каждую конфигурацию и изучать её в деталях. Для этого достаточно Git, Git LFS и Docker Compose. Всё запускается в контейнерах. Даже примеры на Java собираются через Docker multi-stage build.

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

Uber — это хороший пример System Design задачи, где сочетаются geo-search, real-time уведомления, многошаговый workflow и строгие требования к согласованности. В статье разберём, как проектировать такую систему, чтобы она быстро находила водителей поблизости, гарантировала назначение водителю только одной поездки и выдерживала пиковую нагрузку.

Почему в нашей платформе роль API Gateway по-прежнему выполняет Apache APISIX, хотя альтернатив на рынке хватает?

В этой статье без долгих рассуждений разбираю наш выбор: какие требования были у платформы, как мы проверяли кандидатов, где возникали спорные моменты и почему в итоге остановились на связке APISIX, OIDC, Keycloak и OPA.

Агент «Исследовать» в Алисе AI может работать до 20 минут. За это время он успевает обойти десятки сайтов, запустить модели, вызвать инструменты — и сделать всё это параллельно на нескольких хостах. И если в середине цепочки что-то упадёт (а практика показывает, что если может упасть — когда-нибудь упадёт: релизы, сети, «луна не в той фазе»), агент должен уметь продолжить работу с того же места, а не начать всё заново, сжигая часы и LLM-токены. Ещё год назад никакой инфраструктуры для этого у нас не было.

Меня зовут Алексей Логинов, я ведущий разработчик в команде, которая отвечает за инфраструктуру нашего ассистента. В этой статье я покажу, какой путь мы прошли от наивного SDK до полноценной платформы Agent Transport System (ATS) — и как при этом упирались в различные ограничения и преодолевали их.

В ИТ любят слово «отказоустойчивость». Оно звучит инженерно и успокаивающе. Кластеры, зеркала, репликации — всё это создаёт ощущение контролируемости. Но последние десять лет показали неприятную вещь: большинство катастроф происходят не потому, что что-то сломалось, а потому что инфраструктуру целенаправленно уничтожили. Бла-бла-бла.

В данной статье, я расскажу о том, как возможно DDD сейчас обретает своё третье перерождение. Первое в 2003 году, по выходу книги, второе с выходом микросервисов и пониманием гранулярности, и последний - с развитием ИИ.

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

То, что найм в IT сломался - понятно всем. А что же на самом деле происходит? И что делать? Можно пытаться играть в эту игру - кто кого удачнее обманет. Давайте подумаем куда это может завести. И может есть другой путь?

Docker Swarm предоставляет встроенный механизм управления секретами: пароли, ключи API и сертификаты передаются в контейнеры через зашифрованный канал и монтируются в /run/secrets/. Звучит безопасно — пока вы не осознаете, что любой пользователь с доступом к docker exec может прочитать эти секреты в любой момент жизни контейнера.

В этой статье я разберу, почему стандартные способы защиты не работают, и покажу решение на основе именованных каналов (FIFO), которое позволяет секрету быть прочитанным ровно один раз — при старте приложения.

В билетном сервисе сразу несколько сложных задач: нужно исключить double booking, обновлять карту мест в реальном времени и выдерживать read-heavy нагрузку на каталог событий. Разберём архитектуру системы и ключевые технические компромиссы.

Всем привет, меня зовут Кирилл Вересников, я бэкенд-разработчик в iSpring.

Мы делаем iSpring LMS — платформу для корпоративного онлайн-обучения. Исторически это был модульный монолит на PHP, а затем система начала постепенно дополняться микросервисами. Самые нагруженные и часто меняющиеся части мы выносили из монолита, а новый функционал всё чаще сразу делали в микросервисах.

Эта статья будет полезна тем, кто:

- постепенно выносит части монолита в сервисы;

- устал от старых nginx-конфигов, которые годами копились ради обратной совместимости;

- ищет способ стандартизировать входной трафик и убрать бизнес-логику из прокси;

- выбирает между nginx и envoy.

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

Я прикинул, и понял, что проблем там гораздо больше, чем кажется ..