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

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, система должна проверить билет и пустить человека. Главное условие - один билет используется ровно один раз.

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

Чем покупка букета на 8 Марта через Яндекс Еду отличается от покупки, собственно, еды? С точки зрения пользователя — ничем. Выбрал, оплатил, доставили. А вот с точки зрения разработчика бэкенда заказ уникальных букетов превращается в нетривиальную инженерную задачу синхронизации складских запасов. Задержка синхронизации хотя бы в 10 минут трансформируется в звонок и сборщиков заказов, сообщающих о том, что именно такого букета на складе больше нет. 

Меня зовут Виталий Московкин, я занимаюсь ритейлом в Яндекс Еде. В статье я расскажу, как мы синхронизировали состояние складов с 18 миллионами уникальных товаров: сначала с помощью PostgreSQL, а затем с помощью YDB. Такое количество товаров превращается на бэкенде в 4 миллиарда записей о ценах и стоках, которые нельзя просто так кешировать. Но и замена монолитной СУБД на распределённую тоже задача не на десять минут. Подробности — под катом.

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

В статье вы найдёте:

▫️ живые примеры из реальных аварий (включая историю с бесконечными ретраями в очереди),
▫️ три готовые диаграммы в формате Mermaid, которые можно сразу использовать в документации,
▫️ чёткий алгоритм выбора стиля под вашу задачу.

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

За свой многолетний опыт я не встречал основательного подхода к логам приложений.
Часто я слышал фразы: "что нужны логи", "логи плохие" и т.д.
Но они слишком общие и могут означать все и ничего одновременно.

Предлагаю детально разобраться, как именно можно писать логи в этой статье.