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

Меня зовут Миша, я бэкенд‑разработчик в платформе Яндекс Еды, и в этой статье я расскажу о принципах работы Temporal: почему мы его выбрали как основу нового процессинга, в чём его сильные стороны и как изменилась наша жизнь после перехода. 

Раньше для такого требовались: стейт‑машина с полудюжиной состояний, очереди и воркеры, обработчики на каждое событие и блокировки от race conditions. Теперь всё это описано в одной функции, которая вообще выглядит как псевдокод. 

Магия? Нет, Temporal. 

С тех пор как мы перенесли процессинг на Temporal, разработка существенно упростилась. Пользователь оплачивает заказ, ресторан его подтверждает и готовит, курьер забирает и привозит — ровно это и отражено в коде. Ну разве не прелесть?

Вы проектируете масштабируемую систему на System Design интервью в BigTech. Всё идёт хорошо, пока вам не задают неожиданный вопрос. От ответа на который зависит ваше прохождение.

Разберём 10 популярных вопросов, ответы со схемами и примерами в ультимативном чеклисте. И закроем для себя этот важный аспект интервью.

Всем привет! Меня зовут Сергей, я занимаюсь backend-разработкой уже больше 15 лет, а последние несколько лет разрабатываю объектное хранилище для ваших файлов в компании Сloud.ru. Мы пишем свое собственное распределенное хранилище данных с нуля.

В этой статье я хочу рассказать про грабли, которые часто вижу в проектах и на которые периодически наступаю сам. Рассказываю, как их избежать, чтобы сделать ваши сервисы более стабильными и предсказуемыми. Статья будет полезна junior- и middle-разработчикам.

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

Вместо 3 часов дебага падающего Prometheus вы смотрите дашборд, который показывает 99.9% uptime вашего мониторинга.

Это реальность с правильно настроенным стеком на основе VictoriaMetrics.

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

В статье разберемся, что именно начинает ломаться в outbox-паттерне под нагрузкой, как выбирать и блокировать события в разных СУБД, почему ретранслятор стоит отделить от API и какие гарантии доставки на самом деле получаются. А ещё — почему консюмеры должны быть идемпотентными, как следить за внутренней очередью в базе и не узнавать о проблемах уже после инцидента.

Распределенные системы (aka микросервисы) набрали популярность и применяются все шире в современных реалиях. Сервисов становится больше, привычные задачи для них решаются сложнее, усложнились и вопросы аутентификации и контроля доступа.

В статье рассмотрим различные подходы использования API Gateway как части более общего API security-решения в контексте его работы с токенами доступа, выделяя преимущества, недостатки и связанные с ними вопросы безопасности. Также разберем, почему нужно ограничивать область действия access token и может ли API Gateway помочь и в данном вопросе.

Статья написана на основе материала, с которым выступал на PHDays 2025 и CodeFest 15.

Привет, Хабр! Меня зовут Алексей Ситка, я старший разработчик и техлид сервиса уведомлений в Lamoda Tech. Последние годы я занимаюсь проектированием микросервисных приложений из десятков подсистем, в основном в сфере e-commerce. Расскажу, как мы проектировали наш сервис уведомлений, и что у нас получилось. Надеюсь, это будет полезно для тех, кто занимается или интересуется архитектурным планированием. 

Из первых уст рассказываю как переход на Temporal обеспечил надежную доставку клиентских услуг в контексте обычного хостинга.

Когда у вас есть глобальная платформа с тысячами машин по всему миру, самая болезненная часть — не сервера и не сеть, а согласование того, кто и где сейчас жив. Команда Fly.io уже успела пройти через зависшие прокси по всему парку, «заразный» дедлок в Rust, DDL-миграции в глобальной базе состояния и истории, когда попытки восстановить соединение с Consul превращали инфраструктуру в обогреватель аплинков.

В статье разбирается, как из этих факапов родился Corrosion — сервис-дискавери на Rust и SQLite без распределённого консенсуса и центрального хранилища, построенный по мотивам протоколов маршрутизации вроде OSPF и CRDT-репликации. Это история не только о том, как устроен инструмент, но и о том, какие архитектурные решения для распределённого состояния реально живут в продакшене, а какие красиво смотрятся только на диаграммах.

Представьте: вы строите систему верификации дипломов. Требования простые — данные должны быть неизменяемыми (привет, блокчейн) и при этом быстро доступными для запросов (привет, PostgreSQL). Казалось бы, идеальное решение — писать в оба хранилища. Но дьявол, как всегда, кроется в деталях.

Наш проект использует паттерн двойной записи (Dual-Write):

Solana — гарантирует неизменность и прозрачность данных о выданных дипломах

PostgreSQL (Supabase) — обеспечивает быстрые выборки и сложные запросы

Звучит красиво на архитектурных диаграммах, но в production всё не так радужно. Главная проблема — частичные сбои. Транзакция в Solana прошла успешно, диплом записан в блокчейн навечно, а вот запись в PostgreSQL упала. Пользователь получил подтверждение, но половина системы о его дипломе не знает.

Сегодня я покажу, как мы столкнулись с этой проблемой лицом к лицу и какие паттерны применили для её решения.

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

События разворачивались в нескольких реальностях. В первой заказ не пришёл. Во второй - произошло несколько списаний средств. В третьей система упала посередине процесса, оставив данные в не консистентном состоянии.

А четвертая оказалось самой интересной. Где даже с неполадками сети и падениями сервиса был сделан лишь один заказ. И произведена одна оплата. Благодаря чему пришла желаемая теплая пицца. Которую хотел наш дорогой покупатель.

Погрузимся в проблематику оформления заказа, консистентности данных. И схлопнем все реальности в нужную с помощью Outbox Pattern.

Привет, Хаброжители! Сегодня мы делимся с Вами переводом статьи о распределенном монолите.

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

Мы подробно описываем коварные симптомы: кошмары версионирования, паралич развертывания и эрозия автономии команды. На ярком примере из реальной жизни — системе «Drive» и доставки на дом Carrefour — мы раскрываем основную проблему: внутреннюю модель, удерживаемую внешними стандартами. Затем мы раскрываем освобождающие решения: принятие по-настоящему нативных бизнес-моделей и разрыв цепей общих «основных» библиотек кода в пользу явного промежуточного программного обеспечения и надежных API-контрактов. Это путь не только к коду, но и к возвращению обещаний микросервисов.

Вы уже научились отслеживать среднюю скорость запросов на проекте, и это большой шаг. Без преувеличений и какой либо иронии.
И теперь, когда вы перешли от "не измеряем ничего" до "измеряем среднее" — вы попали в ловушку.

Пока вы с удовольствием наблюдаете в отчетах красивые 200ms — ваши пользователи стучат в службу поддержки со словами "у меня все висит".
И они не врут, у них действительно TTF порядка 6 секунд. Но и вы не врете, у вас действительно 200ms в отчете!

Врет метрика, а вы ей верите.

Давайте разбираться.

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

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

Сергей Виноградов на конференции Data&ML2Business рассказал про разработку и построение DWH для задач Яндекс Пэй. В этой статье — дополненный рассказ о том, как устроена аналитическая платформа на базе Greenplum® и ClickHouse®, которую решили строить на базе managed‑сервисов в облаке. А также о том, как жизнь аналитиков облегчает связка Apache Spark™ и Jupyter‑ноутбуков в Yandex DataSphere.

Говоря о серьезных кластерах в компаниях, нам часто приходится взаимодействовать со сторонними отделами и их данными. И зачастую, когда речь идет об ad-hoc, самый эффективный инструмент - Trino. Он удобен тем, что в платформе данных можно добавить каталог, который позволит по сути избежать настройки коннекшена для конечного пользователя. Просто в запросе указываешь название каталога данных и трино сам понимает, что нужно взять данные со сторонней базы данных. Но все меняется, когда выразительности SQL нам перестает хватать для выполнения поставленных задач и мы переходим в Spark. Точнее, менялось. С релизом Spark 3.0 появилась возможность взаимодействовать с внешними источниками так же просто, как в Trino.

Одна из открытых пока задач в области баз данных - поддержание базы данных в консистентном состоянии одновременно на нескольких экземплярах СУБД (узлах), принимающих клиентские соединения независимо друг от друга. Суть проблемы заключается не в том, чтобы синхронизировать состояние удалённо по сети, а в том, что в случае отказа одного из узлов такой системы остальные должны продолжить свою работу без перерыва: принимать соединения, коммитить транзакции не потеряв при этом консистентность. Аналогией для случая одного экземпляра СУБД здесь может быть, к примеру, обеспечение работы при отказе планки оперативной памяти или прерывающемся доступе к нескольким ядрам процессора.

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

Привет! Меня зовут Макс, я web-инженер и предприниматель. В этой статье расскажу о кейсе, где мы с командой работали над непростой интеграцией Pixel Streaming - и как из эксперимента это почти стало продуктом.

С клиентом, который поставил такую задачу, я успел поработать в разных форматах - и в найме, и в статусе подрядчика. Проект, который начался как легаси, содержал множество камней под ногами: нестабильная инфраструктура, высокая стоимость масштабирования и довольно расплывчатая зона ответственности между командами. Тем не менее, нам удалось довести его до состояния, близкого к production-ready - хотя и не запустить в прод по итогу.

В статье разбираются возможности распределённых вычислений в Apache Ignite 3. Покажу, как развернуть кластер в Docker, задеплоить собственные джобы и сравнить Ignite 3 с предыдущей версией. Затронем новые возможности Ignite как полноценной распределённой платформы, а не просто in-memory кэша.