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

Фискальный накопитель печатает чек — и связь обрывается до того, как пришёл ответ. Напечатался он или нет, узнать неоткуда: обе ситуации выглядят для сервиса одинаково. Повторить вслепую — риск юридически значимого дубля, не повторять — продажа без чека. Разбираю, как это решалось в облачной фискализации на сотни миллионов чеков в сутки: отдельное состояние «результат неизвестен», сверка с архивом накопителя по собственному идентификатору в реквизите чека, блокировка слота вместо продолжения наугад — и почему за корректность пришлось заплатить отказом от жёсткой временной гарантии. Первая часть из шести.

Двухфакторная аутентификация давно стала стандартом защиты корпоративных систем. Но для работы с персональными данными и другими критичными операциями проверки только при входе в систему может быть недостаточно. В этой статье разберем, чем Step-Up Authentication отличается от классической 2FA, в каких сценариях она применяется и как мы реализовали этот механизм в одном из наших проектов

Какое‑то время назад, проработав 3 года на позиции Java Middle+‑ разработчика на крупном монолитном легаси‑проекте (естественно, модульном), я столкнулся с тем, что не имел практики в создании приложений на микросервисной архитектуре. При этом я понимал, что работа с микросервисами — это работа с актуальным стеком технологий в мире Java. И если ты не работаешь с микросервисами, то ты вроде как не имеешь необходимой квалификации для большинства вакансий на рынке труда. По крайней мере, если судить по самим вакансиям.

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

Когда вы открываете Яндекс Go для заказа такси и вводите адрес, приложение за доли секунды показывает цену. Кажется, что это несложно: Кажется, что это несложно: взять расстояние и время в пути, умножить их на значения из тарифа. На самом деле, за этой ценой стоит не один десяток факторов — например, скидки, спрос, геозоны. И это ещё без учёта того, что пассажир взял с собой кота или лыжи.

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

Спросите себя, что было результатом расследования сбоя десять лет назад, пять, год. Ответ будет примерно одинаковый – скриншот графика в рабочем чате и фраза «похоже, это база». Давайте посмотрим, что поменялось в 2026-м и как выглядит разбор аварии с помощью ИИ-агента.

Изначально это был монолитный портал на Laravel 8, где user фронт и admin фронт лежали рядом с беком в одной папке. 

Проект ставился каждому клиенту на его собственный хостинг, и единого портала «для всех» не существовало, между клиентами отличался и бек, и фронт. 

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

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

Поэтому, когда появилось время, я занялся этим проектом. Сразу поставил рамку, фреймворк не меняю, остаёмся на Laravel 8. Хотелось не переходить на другой язык, не заниматься переписыванием всего огромного бека, отделить всё в модули и переписывать уже поэтапно отдельные куски.

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

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

От проблем PostgreSQL к скорости ClickHouse. Рассказываем, как переработали архитектуру кеширования для AI-тестов, чтобы выполнять более 2 млн запросов и обрабатывать 20 млрд записей в день, сохранив среднюю задержку поиска элементов на уровне 250 мс.

Почти любая распределенная платформа рано или поздно сталкивается с необходимостью синхронизировать данные между своими системами. И чем выше требования к надежности и скорости доставки изменений, тем меньше остается простых решений. Бизнес-пользователям при работе с интерфейсом одной из платформ нужно знать о сущностях, заведённых во второй. Первая хранит их в реляционной СУБД (неважно, какой именно), а вторая - в документоориентированной MongoDB. До кучи, обе платформы разнесены по сети. Можно, конечно, предложить открыть оба интерфейса бок о бок и сверять данные глазами. Но это справедливо негативно скажется на финансовом обеспечении команды разработки, да и как-то не по-человечески так относиться к своим коллегам. Поэтому приходится зарабатывать доверие в коллективе честным трудом.

Встаёт вопрос: как в условиях распределённой структуры наладить транспортировку данных для взаимодействия независимых систем? Прикручивать ко всем продуктам кастомные интеграции дорого и непродуктивно. 

В данной статье хочется представить вам, как мы реализовали интеграцию двух независимых платформ со своими базами данных при помощи инструментов MongoDB для мониторинга данных и брокера сообщений. Описать путь от самого простого решения на примитивных выгрузках метаданных одной пачкой до реализации на событиях Change Stream посредством брокера сообщений.

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

В статье разберём, какие подходы помогают выстроить устойчивое межсервисное взаимодействие — от агрегаторов и API Gateway до GraphQL и CQRS — и где у каждого решения есть свои ограничения.

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

Но вот какова правда: для корректной работы продьюсеров в событийно-ориентированной системе не обязательно упорядочивать события. Действительно не обойтись без свойств, обеспечивающих правильный контекст — такой информации, как номера версий, метки времени updatedAt и идентификаторы объектов, по которой потребители могут самостоятельно судить о свежести и согласованности событий.

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

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

Пятнадцать модулей, три ноды за балансировщиком, RabbitMQ и Kafka по три ноды, PostgreSQL, Redis из шести.

В распределённых системах генерация уникальных ID быстро становится архитектурной задачей: центральная база создаёт узкое место, а переход на UUID может оказаться невозможным из-за унаследованного кода. Разберём рабочий подход с отдельным сервисом, диапазонами идентификаторов и защитой от потери ID при сбоях.

Как организовать контрактное тестирование, если у вас 150+ микросервисов, 10 команд и QA есть далеко не везде? В Nexign перепробовали готовые инструменты, дважды откатили собственные решения — и в итоге за четыре дня собрали прототип, который за полтора года превратился в рабочий инструмент без единой строки тестового кода. Ведущий инженер Максим Дубинин рассказывает, что не так с Dredd и Pact и почему иногда проще сделать своё.

Разбираем систему управления транспортом — TMS. Заказы приезжают из SAP, под них подбираются водитель и машина с учётом требований, рейс идёт по точкам с временными окнами, на точках чек-листы, при выдаче и возврате машины — акты с фиксацией повреждений. Сверху поток GPS в партиционированные таблицы, отслеживание рейсов и мест, мобильное приложение водителя и публичный контур, где клиент видит свою доставку. Пятнадцать модулей, три ноды за балансировщиком, RabbitMQ и Kafka по три ноды, Redis, PostgreSQL, отдельный сервер идентичности.

Систему стали писать, когда TMS покупали как услугу у внешних поставщиков и риски выросли: собственная разработка оказалась способом вернуть управляемость ключевым процессом. И написали быстро — системе год и четыре месяца, первый коммит в апреле 2025-го. Это не легаси из нулевых, а молодой проект, который уже успел обзавестись инфраструктурным слоем и уже начал его разбирать.

Команда была ....

Разбираем систему управления транспортом — TMS. Не игрушечную и не с конференции: заказы приезжают из SAP, под них подбираются водитель и машина с учётом требований к транспорту и к точкам, рейс идёт по точкам с временными окнами, на точках — чек-листы, при выдаче и возврате машины составляются акты с фиксацией повреждений. Сверху — поток GPS-координат в партиционированные таблицы, отслеживание рейсов, мест и контрагентов, определение присутствия по WiFi. Плюс мобильное приложение водителя и публичный контур, где клиент видит, где его доставка.

Пятнадцать модулей, три ноды за балансировщиком, RabbitMQ и Kafka по три ноды, Redis, PostgreSQL, отдельный сервер идентичности.

Зачем её вообще стали писать. TMS покупали как услугу у внешних поставщиков, и риски выросли.

Это стоит развернуть, потому что решение принималось не по техническим мотивам. Когда ключевой процесс компании работает на внешнем сервисе, риск считается деньгами: простой, на который вы не влияете; сроки исправлений, которые определяет не ваш приоритет; зависимость от одного поставщика при смене условий. Пока риск невелик, покупать дешевле, чем строить. Когда он вырастает — арифметика переворачивается, и собственная разработка становится способом вернуть управляемость, а не способом сэкономить.

Систему забрали себе.

И вот главное ...

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

В статье — шесть шагов, которые помогают превратить разрозненные требования в управляемую архитектуру сквозного процесса.

Всем привет! Меня зовут Григорий, и недавно при разработке своего микросервисного приложения я нашёл уязвимость — сообщения, пересылаемые между сервисами, имели высокий риск быть необработанными. Решением стал паттерны Outbox и Inbox. Однако, когда я стал их реализовывать во всех приложениях, то понял, что просто копирую и вставляю код. Чтобы это исправить, я решил написать свой стартер.

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

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

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

Стек: типизированное хранилище redb поверх PostgreSQL, интеграционный движок redb.Route, рантайм redb.Tsak и сервер идентичности redb.Identity. Всё Pro, всё бесплатно на линейке 3.x.

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

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

Мы четыре года строим экосистему redb — типизированное хранилище поверх PostgreSQL, MS SQL и SQLite, интеграционный движок, рантайм с кластером и дашбордом, и сервер идентичности с поддержкой OAuth 2.1 и OpenID Connect. Всё это работает в проде, публикуется пакетами и образами, и — важное для этой статьи — все Pro‑возможности бесплатны на всей линейке 3.x, без ключей и лицензионного сервера.

Ниже — разбор платёжной платформы по трём слоям, с расчётом, где именно уходят человеко‑годы. Без кода: технические разборы у нас есть отдельно, здесь речь про деньги, сроки и риски.