Микросервисы *

Что будет, если больше 200 бэкенд‑разработчиков вносят изменения 2–3 раза в неделю в более чем 400 микросервисов, написанных на пяти разных языках — C++, Go, Python, Java и PHP? Ответ хорошо знаком любому, кто сталкивался с быстрорастущей распределённой системой: хаос появляется быстрее, чем успеваешь его отлавливать. И в какой‑то момент становится очевидно, что нужна надёжная точка контроля, чтобы поддерживать архитектуру в рабочем состоянии.

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

Всем привет, уважаемые читатели! В архитектуре проектов мы можем наблюдать применение паттерна BFF (Backend for frontend). При этом BFF может быть в архитектуре, где есть взаимодействие с клиентскими приложениями: веб, мобильное, смарт-устройства и т.д, но может быть всего-навсего один служебный фронтенд, доступ к которому возможен во внутрикорпоративном сегменте, например, банковская система, hr, логистика. Кажется, что при наличии одного фронтенда введение BFF избыточно.

И возникает закономерный вопрос: если клиент всего один, да еще и работает внутри защищенного контура, зачем нам плодить отдельные компоненты системы? Не превращается ли BFF в лишний прокси-сервис, который только пробрасывает запрос и добавляет сетевую задержку?

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

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

В материале можно посмотреть, как изящно связать свойства  и абстрактные классы с реализацией принципа DRY .

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

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

Абстрактные методы - методы с декоратором @abstractmethod, которые обязаны быть реализованы в дочерних классах.

Абстрактный класс может содержать как обычные, так и абстрактные методы.

Свойство - реализуется через декораторы @property (для чтения) и @<name>.setter (для изменения и валидации) обеспечивая инкапсуляцию, делая API удобным, при этом позволяя менять внутреннюю реализацию без изменения внешнего кода.

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

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

Проблема: никто не знает, кто кого вызывает

В 2012 году биржевой брокер Knight Capital потерял $460 миллионов за 45 минут.
Причина — активация устаревшего модуля, который начал массово размещать ордера.
Отчёт SEC указал на ключевую ошибку:

Для кого статья: для техлидов и системных аналитиков (SA), архитекторов ПО.
О чём статья: об использовании некоторых удобных, современных подходов к проектированию ПО на стеке Java-Spring в enterprise в условиях большого количества команд и большой неопределенности. 
Об авторе: лид стрима в облачном провайдере, в 2024-2025 гг. с коллегами разрабатывавший подходы к архитектуре микросервисов.

В условиях современной разработки, когда компании растут, а команды распределены по офисам и странам, классические подходы к проектированию часто становятся узким местом. Хаос в интеграциях, бесконечные согласования форматов данных и конфликты из-за изменений в API — это знакомые боли для многих архитекторов и тимлидов. Если вы тоже сталкивались с трудностями и конфликтами при разработке платформ с множеством микросервисов или хотите разрабатывать и не хотите сталкиваться – эта статья будет наверняка интересна.

Разбираем на практике, как гарантировать доставку сообщений в Kafka/RabbitMQ без распределенных транзакций, используя паттерн Transactional Outbox.

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

Всем привет! Меня зовут Максим, я Go-разработчик в Wildberries & Russ. В высоконагруженных системах сотни сервисов взаимодействуют ежесекундно, и любой малейший простой системы напрямую влияет на прибыль бизнеса. Чтобы уметь быстро находить причины и устранять их за короткие сроки придуманы инструменты, обеспечивающие наблюдаемость приложения. Сегодня поговорим о том, как обеспечить observability и почему без нее жизнь продукта превращается в «черный ящик».

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

Два месяца назад я писал на Хабр о первом релизе Funxy — гибридного языка программирования. Тогда это был эксперимент по созданию своего языка с выводом типов, императивного, с функциональными возможностями.

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

Стабильность: десятки багфиксов — падения на валидном коде, рекурсия, edge-кейсы VM

Рантайм: tree-walk интерпретатор → стековая VM (быстрее, легче по памяти)

Язык: const, return, лямбды (\x -> x + 1), list comprehensions, block syntax для DSL

Типы: strict mode, flow-sensitive typing

Тулинг: LSP и дебаггер

Embedding: встраивание Funxy в Go-приложения как скриптовый движок

Архитектуры корпоративных ИТ-систем стоят на пороге структурных изменений. Их причина - в совмещении двух подходов, которые долгое время развивались параллельно - микросервисные архитектуры и AI-агентные платформы.

Микросервисы стали стандартом построения масштабируемых и надежных корпоративных систем, особенно для таких классов, как ERP-системы, для которых важны детерминизм, воспроизводимость результатов, контроль и соответствие регуляторным требованиям [1][2][5].

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

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

В этой статье впервые представлена архитектурную модель, которая позволяет объединить эти два подхода в единую управляемую архитектуру.

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

Меня зовут Никита Шехов, я руковожу командой разработки «Единой цифровой платформы» (ЕЦП) в РСХБ.Цифра. В этой статье хочу рассказать, как мы создавали платформу для автоматизации бизнес-процессов банка, с какими вызовами столкнулись и какие решения оказались ключевыми. Вайб того времени: у нас было два часа на сон, семьдесят пять созвонов в день, пять бизнес-линий или стримов, план, целиком наполненный большими амбициями, целое море разношерстных систем, продуктов и групп разработки, а также ящик прогхантерского энергетика, литры чистого адреналина, ящик зеленого мерча и 12 пузырьков жидкого магния. 

Если ваш API-клиент выглядит как башня декораторов — вы уже в зоне инженерной боли. Рассказываю, как я из этого выбрался.

Как правильно обрабатывать ошибки в Spring Kafka, чтобы консьюмеры не падали? Что такое Dead Letter Queue / Topic?

Простым языком и с примерами кода о паттерне обработки ошибок.

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

Хотим вам рассказать об одной из первых наших новинок 2026 года, которую с тем же успехом можно считать и вторым изданием, и переизданием отлично зарекомендовавшей себя книги о микросервисах. Речь под катом пойдёт о книге Юлии Поповой «Go: разработка приложений в микросервисной архитектуре с нуля».

И даже до выхода у этой книги уже есть история.

Привет, Хабр! Меня зовут Алексей Кутневич, я работаю ведущим Архитектором в ЦК архитектуры БЦТ РСХБ-Экосистема. В этой статье хочу поделиться реальными кейсами оптимизации микросервисной архитектуры из проекта «Свои финансы» — нашего нового банковского приложения. Покажу, как эти решения помогли существенно улучшить производительность системы. 

В этой статье речь пойдет о добавлении в С++ приложение функционала сохранения данных в формате YAML с использованием библиотеки yaml-cpp. Мы подробно рассмотрим какие возможности для этого предоставляет библиотека и на какие подводные камни можно наткнуться в процессе ее использования.

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

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

Современные комплексы бизнес-приложений отличаются высокой сложностью, из-за чего могут происходить сбои - сообщения теряются, consumer’ы падают, очереди переполняются. Поделимся реальным кейсом, в котором Eventual Consistency удалось обеспечить без серьезной переработки существующих систем.

Обеспечение Eventual Consistency в сложных системах

Уже давно стандартом де-факто стали микросервисы, поэтому практически любая система представляет собой набор компонентов, взаимодействующих между собой как синхронно (например, по REST), так и асинхронно — через шины сообщений (RabbitMQ, Kafka).

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

Где именно все может сломаться

Предположим, у нас две системы:

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