Почему приложение тормозит, хотя код работает как надо? Когда микросервисы начинают создавать больше проблем, чем решать? И насколько далеко можно зайти с автоматизацией разработки с помощью ИИ-агентов? В ноябре преподаватели OTUS разберут эти и другие вопросы на 52 бесплатных демо-уроках. В дайджесте — расписание занятий по восьми ИТ-направлениям: от программирования и архитектуры до машинного обучения, информационной безопасности и управления.

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

И мало кто хочет признаться, что в 2026 году он сидит на монолите с Java 8 в бэке. Но есть в этих ваших микросервисах (как и в любой распределённой системе) одна неприятная штука — согласованность данных. Вернее, их несогласованность.

Нет-нет да и разъедутся наборы каких-нибудь транзакций в двух смежных системах.
Знакомо? Наверняка. Вот об этом сегодня и поговорим.

Точнее, поговорим об одном из популярнейших решений проблем распределённых транзакций —шаблоне Transactional Outbox. Пройдём путь от поделки на коленке до prod-like версии. Попробуем сделать это без тонн кода, сиквенсов и прочей «духоты», ограничившись лишь простыми наглядными примерами.

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

Представим, что мы разрабатываем сервис для прослушивания музыки — Пай.Музыку. В него уже заходит больше 100 тысяч пользователей в месяц, в команде работает 10+ инженеров, а недавно к музыке добавились подкасты и личный кабинет музыканта. Новые направления хочется часто обновлять и отдельно масштабировать (из-за разной нагрузки), основную логику — релизить пореже. Но пока всё живёт в одном монолите: общий релизный цикл тормозит команды, а изменения в одних и тех же файлах приводят к мерж-конфликтам.

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

На примере этой системы разберём семь паттернов микросервисной архитектуры, их ограничения и короткие примеры на Python.

В этой статье слова “сервис” и “микросервис” используются взаимозаменяемо.

Самая дорогая строчка в микросервисе с LLM — model="gpt-4o". За ней тянутся свой ключ вендора, свои ретраи и счёт, который потом некому разобрать.

Расскажу об одной идее, которая это убирает: сервис не должен знать, какая модель ему отвечает. Вокруг неё четыре механизма: правила маршрутизации, автоматический выбор сложности, поведение при сбоях вендоров и контроль денег. Примеры — из нашего open-source шлюза Keystone (KTMS) на Go, но схему можно повторить в любом шлюзе.