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

После миграции с ClickHouse на StarRocks NAVER существенно оптимизировала обработку многотабличных JOIN. StarRocks повысил производительность запросов, обеспечил бесшовное масштабирование и позволил построить единый слой запросов, совместимый с множеством источников данных. Эти улучшения позволили предоставлять инсайты в реальном времени и поддерживать принятие решений на основе данных во всей экосистеме NAVER.

В начале 2010-х в профессиональном сообществе разработчиков и архитекторов распределенных систем широко обсуждалась идея, что мир баз данных вступает в новую эру. На фоне успехов крупных интернет-сервисов термин BASE начал использоваться как противопоставление классическому ACID. Хайп вокруг NoSQL, CAP-теоремы и масштабируемых систем породил лозунги вроде «SQL умер», «ACID — для банков, а мы делаем веб», «eventual consistency — это нормально».

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

Что же произошло? Была ли «битва ACID и BASE» реальным технологическим разломом или лишь отражала ограничения своего времени? 

В этой статье мы разберём, как возникли ACID и BASE, почему BASE быстро стал популярен и что на самом деле означает тезис «победил ACID» в 2020-е годы.

Вы настроили retention.ms = 86400000 (24 часа) и отправили тестовое сообщение. Через сколько времени реально удалится сообщение?

Разбираем типовые сценарии на основе опыта Cloud4Y

Более чем за 15 лет работы мы видели сотни гибридных инфраструктур. Часть из них приносит клиентам ощутимую экономию и окупается за год. Другая часть работает, но особой выгоды не дает. Есть и проекты, где гибридное облако было ошибкой с самого начала. В этой статье разбираем типовые сценарии: когда гибрид работает, когда нет, и как не попасть в ловушку.

В этой статье мы поделимся некоторыми подробностями работы над новыми функциями Greengage, такими как shrink и expand кластера, улучшение вставки для foreign-таблиц и подготовка к интеграции с Apache Iceberg.

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

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

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

Выбор стандарта для security token — это архитектурное решение, которое определит compliance-модель, gas costs, интеграционные возможности и upgradeability на годы вперёд. В этой статье я разберу два основных стандарта — ERC-1400 и ERC-3643 — с точки зрения разработчика, который имплементировал оба.

Мы в Ситидрайве строим микросервисную архитектуру. Сегодня у нас 200+ сервисов, за которыми стоят свыше 20 автономных команд — всего больше 150 инженеров. Казалось бы, идеальная модель: каждая команда быстро выкатывает свои фичи без лишней бюрократии. Но была и обратная сторона — нет единого понимания, какие сервисы действительно критичны, как они связаны друг с другом и куда развивать систему дальше.

Но нам удалось с этим справиться — мы привели сотни микросервисов в порядок и сделали систему предсказуемой. В этой статье я расскажу про путь команды к внедрению тир-листа, модели зрелости, управлению зависимостями и приоритетами инцидентов.

Всем привет! Меня зовут Сергей Бунатян, я руководитель службы в Техплатформе Городских сервисов Яндекса. 

На сегодняшний день существует довольно много брокеров сообщений. Наиболее часто используемыми в индустрии, пожалуй, будут те, которые, реализуют парадигму очереди сообщений. Самых известных представителей вы наверняка знаете, — Apache Kafka и RabbitMQ, а внутри Яндекса широко используется Logbroker. И, тем не менее, как нетрудно догадаться из этого вступления, мы зачем‑то решили написать свой брокер сообщений.

Сегодня я расскажу про нашу систему, которая называется STQ — Sharded Tasks Queue. По названию системы можно было бы подумать, что это ещё один сервер очередей, однако это будет не совсем верно. STQ — это скорее message broker. 

В этой статье я постараюсь рассказать о том, какие задачи перед нами стояли и как это нас привело к решению написать что‑то своё. А заодно поделюсь опытом эксплуатации нашей системы и расскажу про влияние STQ на опыт разработчиков.

Компании ежедневно генерируют большие объемы данных, но далеко не вся информация одинаково важна: со временем многие данные становятся менее востребованными, продолжая занимать дорогие и высокопроизводительные накопители (SSD, RAM). В результате хранение таких «холодных» данных обходится неоправданно дорого, поскольку потребность в постоянном доступе к ним минимальна.

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

Привет, Хабр. Меня зовут Сергей Фомин. Я старший менеджер продукта Tarantool DataBase. В этой статье я расскажу, как именно мы реализовали механизм охлаждения и какие бизнес-выгоды могут получить компании при его использовании.

Меня зовут Миша, я бэкенд‑разработчик в платформе Яндекс Еды, и в этой статье я расскажу о принципах работы 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 упала. Пользователь получил подтверждение, но половина системы о его дипломе не знает.

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