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

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

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

Погрузимся в проблематику оформления заказа, консистентности данных. И схлопнем все реальности в нужную с помощью 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 кэша.

Около года назад я написал первую часть статьи о Single SPA — о том, как я выбирал архитектурный подход, боролся с монолитом и пробовал собрать первые микрофронтенды. В статье были разобраны базовые принципы работы Single SPA, подключение importmap, сравнение с другими архитектурными решениями и настройка сборки на Webpack и Vite.

Эта статья — продолжение цикла. Здесь я поделюсь практикой: как на самом деле живётся с Single SPA, какие есть подводные камни и что можно вынести в виде рекомендаций.

Сразу скажу: Single SPA — не «серебряная пуля» и уж точно не современный тренд фронтенд-разработки. В 2025-м появилось еще больше других подходов, которые решают похожие задачи иначе. Но Single SPA всё ещё актуален там, где есть огромные легаси-системы, которые невозможно переписать с нуля. И вот именно для таких кейсов мой опыт может быть полезен.

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

Хочу поделиться своим путём в блокчейн. К 2023 году за плечами было уже 7 лет строгого режима веб-разработки, и она начала казаться рутиной. Хотелось нового. В идеале — области, где можно было бы применить свою любовь к математике. Выбор стоял между датой и блокчейном. Я выбрал второе — во многом потому, что несколько моих друзей уже погрузились в этот «тёмный лес» и своими проектами пробудили во мне интерес. Это решение привело меня к неожиданным открытиям, трем разным проектам, нескольким месяцам жизни на доширак и к пониманию, что блокчейн — это идеальный полигон для любого разработчика, увлеченного математикой.

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

Международная команда ученых совершила прорыв в области распределенного машинного обучения, разработав новые алгоритмы, значительно повышающие эффективность обучения моделей в федеративных сетях. Исследование, проведенное учеными из Университета имени Короля Абдуллы ( Саудовская Аравия), Московского физико-технического института (МФТИ), Университета Мила и Монреальского университета (Mila, Канада), Университета имени Мухаммеда бен Зайда по искусственному интеллекту (MBZUAI, ОАЭ) и Принстонского университета (США), представляет собой значительный шаг вперед в решении проблемы высокой вычислительной сложности обучения больших моделей в распределенных системах. Результаты опубликованы в материалах конференции NeurIPS 2024.

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

Группа российских ученых из МФТИ, Сколтеха и Научно-исследовательского центра искусственного интеллекта Университета Иннополис разработала революционный алгоритм для решения сложной задачи децентрализованной оптимизации. Результаты исследования опубликованы в материалах конференции NeurIPS 2024.

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

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

Это доставка событий через БД, в которой хранится состояние распределённого приложения.

Два года назад все началось с первого коммита и туманного понимания, что мы вообще хотим сделать. Сегодня — два мажорных релиза, собственный модуль миграций, документация, тренинги и пользователи, которые безболезненно перешли на новую версию по нашим инструкциям. Но путь от «кучи кода для внутреннего использования» до полноценной коробочной In-memory-базы оказался совсем не прямым. 

Меня зовут Александр Кленов, я тимлид разработки Tarantool DB в команде Tarantool. Я расскажу историю о том, как мы брали зрелый, но очень гибкий Tarantool Enterprise и превращали его в решение, которое можно установить из коробки.

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

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

Хорошо спроектированный и надежный API — это ворота, через которые ваши данные и функциональность взаимодействуют с внешним миром: мобильными приложениями, веб‑сайтами, партнерскими сервисами и даже внутренними клиентами.

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

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