Java *

Всем привет! В данной статье будет описан один из возможных вариантов реализации паттерна outbox transactional. План данной статьи такой. Вначале немного теории, а потом на примере двух микросервисов будет показала реализация данного паттерна с помощью debezium и kafka. Данная статья будет полезна для новичков, которые не встречались с данным паттерном.

Весь код микросервисов будет доступен по ссылкам.

Но вначале немного теории. Самый главный вопрос зачем нужен данный паттерн и какую он решает задачу.

Паттерн Outbox – используется в распределенных транзакциях, то есть в транзакциях, которые проходят и затрагивают несколько микровервисов, для обеспечения гарантированной доставки сообщения от одного микросервиса до другого. Данный паттерн используется там, где очень критично чтобы сообщение не потерялось, даже при сбоях в системе. Outbox паттерн получил распространение именно в микросервисной архитектуре, где нет возможности с помощью одной аннотации обеспечить транзакционность какого-то метода и возможный откат всей транзакции в рамках нескольких микросервисов.

Теперь перейдем к практике.

Допустим у нас имеется два микросервиса: order-servic, в котором клиент заказывает какой-то товар и bank-service, в котором происходит оплата за этот товар.

Весь код микросервисов будет доступен по ссылкам.

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

Для реализации этого паттерна я буду использовать debezium и kafka.

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

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

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

Типичный сценарий: бизнес приходит с задачей "Если в корзине три товара категории "Электроника", положи в подарок чехол, но только если регион доставки не "Дальний Восток". Звучит как if-else на пять строк. Но в распределённой системе это превращается в такой себе квест: BasketService синхронно обращается к Catalog, затем к Warehouse, затем к GeoService. Где-то посередине случается таймаут, где-то - сетевой сбой, и в коде начинают появляться саги, компенсации и ретраи.

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

Я приглашаю сегодня взглянуть на проблему под другим углом. Что если пересмотреть не инструменты, а саму парадигму управления состоянием?

Я активно использую на проекте Kafka Connect Framework и в частности Kafka JDBC Sink Connector для быстрого сохранения данных из Kafka Topic в БД PostgresSQL. Для большинства задач достаточно написать простую JSON-конфигурацию и все стабильно и быстро работает из коробки. Нет необходимости в написании собственного кода. Однако в нетиповых ситуациях расширяемость Kafka Connect тоже помогает - можно переопределить и написать один из компонентов.

В конфигурации JDBC Sink Connector Task существует настройка dialect.name, которая отвечает за выбор диалекта для работы с конкретной БД. Как правило, в 99% случаев используется один из уже реализованных для популярных БД диалектов, как например в моем случае PostgresSqlDatabaseDialect для PostgreSQL.

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

В данной статье я хочу показать идеи того, как реализация своего DatabaseDialect может помочь при имплементации нестандартных сценариев для вполне себе популярной БД Postgres, для которой существует PostgresSqlDatabaseDialect.

Всем привет! Когда речь заходит о разработке высоконагруженных систем, многие предлагают: «python, сделать проще и быстрее». Но есть проблема: Скорость разработки != скорость и качество работы сервиса. Когда мы делаем любой продукт, важны: Масштабируемость, стабильность работы под большой нагрузкой, предсказуемость поведения системы — особенно когда речь идет о тысячах одновременных пользователей, лентах новостей в реальном времени, уведомлениях и сложных связях между разными сущностями.

Именно поэтому и выбрана Java и Spring Boot как основа. Банки, сервисы видео, они работают именно на Java и Spring.

Одна из особенностей: строгая типизация, качественные инструменты для многопоточности, мощная экосистема и предсказуемое потребление памяти делают Java идеальным выбором для систем, где падение = полная потеря пользователей.
Попробую сделать цикл статей по разработке соцсети, которая будет объединять в себе ВК, пикабу, и иже с ними. Не ради «создания продукта который затмит всех и вся», а ради самого программирования.

Итак, начну, среда разработки Intellij Idea. О, точно, весь проект будет доступен из gitLab. Нам необходимо создать файлы с конфигурацией. можно сказать что их обычно 3. Да, я про application.yml. один из них общий, который так и называется: application.yml, и еще два: application-dev.yml и application-prod.yml

Планируешь миграцию на Spring Boot 4.0? Вместе с Eddy Benchek в новом переводе от команды Java Insider разбираем пять неочевидных проблем, с которыми столкнулась реальная production-команда при миграции, и показываем, как их исправить, чтобы вы не потеряли дни на поиски неожиданных багов.

Здравствуйте, меня зовут tmaxx, и я алкоголик понял что такое монады. И, естественно, рассказываю об этом всем вокруг, в том числе и вам. Конечно, это Далеко Не Первая Статья О Монадах на Хабре, но ещё один альтернативный взгляд на проблему, думаю, не помешает.

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

(>>=) :: forall a b. m a -> (a -> m b) -> m b
return :: a -> m a

Не понятно на Хаскеле? Вот примерный эквивалент на Java:

<A, B> Monad<B> bind(Monad<A> ma, Function<A, Monad<B>> famb); <A> Monad<A> ret(A a);

Все равно остались вопросы? Почему именно такая сигнатура? Что в ней такого особенного, что она используется абсолютно во всех реальных программах написанных на функциональных языках? Попробуем разобраться.

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

Мне всегда казалось, что C# сильно лучше нашей Java (только LINQ expressions чего стоит — именно expressions, а не применения типа LINQ-to-objects). А в F# (тоже работает на .NET) есть нормальные провайдеры типов и другая функциональщина. И всё это работает чудесно, а не как Haskell, который несколько лет подряд сегфолтился на Windows, и никто это не чинил.

Но всё портит маниакальная борьба Microsoft с конкурентами и из-за этого отсутствие экосистемы вне продуктов Microsoft. Это отсутствие конкуренции и деградация. Какой дурак захочет связываться с технологией, из-за которой тебя может назавтра кинуть создатель этой технологии? Беда, C# нам тоже не подходит.

В большинстве туториалов по Java-ботам нам предлагают написать EchoBot или магазин пиццы на огромных switch-case конструкциях. Но в 2026 году, когда у нас есть Java 21 и Spring Boot 3, писать бойлерплейт — это преступление против продуктивности.

Сегодня мы напишем WeatherBot — полезного бота, который показывает реальную погоду через API OpenWeatherMap, имеет кнопку обновления "на лету" и, используя FSM (Машину состояний) с валидацией данных, позволяет настроить ежедневную рассылку прогноза.

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

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

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

"Loom" означает "ткацкий станок" - так назывался проект по добавлению асинхронности в джаву. Тяжёлые системные потоки заменили легковесными виртуальными потоками. Потоки и нити в английском называются одинаково - thread - отсюда название.

Проект успешно внедрили пару лет назад, и я, к сожалению, это полностью пропустил. Основная причина, конечно - что я в принципе не ожидал от джавы никаких прорывов (и оказался на 100% неправ!) Ну и, как бэкенд-разработчик на питоне, я не очень-то слежу за развитием JVM-языков.

Но исправляюсь: Project Loom - это блестящая идея. Учитывая, что его внедрили совместимым образом, и почти не было ломающих изменений. Я считаю, это оптимальная реализация асинхронности для высокоуровневого серверного языка.

Уже почти все использующие JVM языки переехали на новую версию JVM, и, таким образом, на проект Loom: деваться им некуда. Так что, есть надежда, что это изменение откроет новую главу для некоторых из них. Есть также предположение, как оно может повлиять на скриптовые языки, такие как питон. Гипотеза только.

Также, вы узнаете, почему Гвидо ван Россум не ошибся, когда добавлял async/await в питон, а Мацумото — создатель Ruby — тоже угадал, когда, наоборот, отказался от async/await.

Пора перестать воспринимать Redis как временное хранилище key-value. Сегодня это многофункциональный движок, объединяющий в себе брокер сообщений с поддержкой Pub/Sub, гео-БД с Spatial-индексами, и надежный инструмент синхронизации через распределенные блокировки (Redlock). Современный Redis, потенциально, может заменить стек из 3–4 узкоспециализированных сервисов.

В новом переводе от команды Spring АйО рассмотрим, как использовать Redis на полную катушку и превратить его в фундамент вашей архитектуры.

В своем кратком тексте 1998 года Энди Хант, отталкиваясь от закона Деметры и принципа разделения команд и запросов, просто и понятно излагает один из важных принципов объектно-ориентированного проектирования — «говори, а не спрашивай». Этот принцип учит делегировать объектам ответственность за их данные, что позволяет создавать слабосвязанные и устойчивые к изменениям системы.

Что делать, когда инфраструктура, сдерживавшая злоумышленников, внезапно начинает мешать легитимным клиентам? В Dodo Payments такой момент наступил в 23:00 в четверг — и стал точкой невозврата.

В новом переводе от команды Spring АйО подробно разберем переход с классического ingress-контроллера на полноценный service mesh. Миграция заняла 11 недель и навсегда изменила подход к платформенной инженерии.

Привет, это снова Егор. Сегодня я подведу итоги моей попытки интегрировать ресивер с умным домом Яндекса.

Настоящая устойчивость систем — в архитектуре. В новом переводе от команды Spring АйО — 8 фундаментальных паттернов проектирования, на которых держатся все современные data engineering-стеки. Освоив их, вы перестанете тушить пожары и начнёте проектировать платформы, которые выдерживают продакшен.

Пишешь на Spring Boot уже пару лет и уверен, что знаешь все подводные камни? Рассмотрим классические ошибки, которые продолжают проникать в прод даже у бывалых разработчиков. Вместе с Mohamed Akthar в новом переводе от команды Java Insider разбираем три распространённые проблемы, которые могут привести к бессонным ночам отладки.

В Veai 5.3 добавлены режимы работы агента (Modes), появился личный кабинет и возможность выбрать модель LLM для индивидуальных пользователей, отображение ИИ-текста стало более плавным и комфортным для восприятия.

В IntelliJ Idea (а, значит, и в OpenIDE) есть встроенный MCP-сервер. Активируется он достаточно просто и позволяет расширять стандартную функциональность command-line кодинговых агентов, таких как платный Claude Code или бесплатный, но тоже весьма неплохой Qwen Code. Преимущество CLI-агентов в том, что они работают с исходниками напрямую, держат контекст всего проекта и сами проверяют компилируемость кода. А MCP-сервер предоставляет такому агенту некоторую функциональность, которая обеспечивается средствами IDE. Поскольку IDE явно лучше заточена под работу с исходниками проекта, чем универсальные агенты, такие действия выполняются быстрее и точнее.