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

6 октября в 12:00 (МСК) компания «Диасофт» проведет вебинар «Продуктовая фабрика» в действии: опыт СДМ-Банка по ускорению расчета комиссий и разгрузке АБС».

Микросервисная архитектура «Продуктовой фабрики» (Digital Q.ProductFactory) создает технологическую основу, которая позволяет быстрее производить расчет комиссий, более гибко настраивать тарифную политику и снижать нагрузку на монолитную АБС.

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

Специалисты «Диасофт» и СДМ-Банка перенастроили бизнес-цепочку, чтобы микросервисная «Продуктовая фабрика» получала необходимый контекст и запрос из АБС, рассчитывала размер комиссии и возвращала результат обратно. При этом АБС распоряжается результатом в соответствии со своими внутренними бизнес-процессами. Банк предоставил техническое задание с различными видами комиссий. Все комиссии были успешно отработаны в пилотном проекте.

«Продуктовая фабрика» быстрее считает комиссии, легче настраивается и позволяет реализовать больше сценариев. АБС при этом «разгружается», что снижает нагрузку на инфраструктуру и упрощает поддержку.

 На вебинаре мы обсудим:

• возможности «Продуктовой фабрики» (Digital Q.ProductFactory) для централизованного управления данными о продуктах и услугах и расчета комиссий;

• архитектуру и сценарии интеграции «Продуктовой фабрики» с АБС: как микросервис получает необходимый контекст и запрос из АБС, рассчитывает размер комиссии и возвращает результат;

• практический опыт СДМ-Банка: отработку различных видов комиссий в рамках пилотного проекта;

• за счет чего банк повысил скорость и гибкость расчета комиссий, упростил настройку тарифной политики и «разгрузил» свою АБС;

• возможности снижения нагрузки на инфраструктуру и упрощение поддержки АБС;

• перспективы промышленного внедрения и тиражирования решения в других банках.

Мероприятие проведут:

• Илья Петров, руководитель разработки решения «Продуктовая фабрика», компания «Диасофт».

• Олег Илюхин, заместитель председателя правления, директор по информационным технологиям СДМ-Банка.

Вебинар будет полезен руководителям и специалистам ИТ-подразделений банков, архитекторам, разработчикам, продуктовым менеджерам, отвечающим за тарифную политику и комиссии, а также всем, кто интересуется переходом от монолитных АБС к микросервисной архитектуре.

Зарегистрироваться на вебинар можно по ссылке.

Как мы провели второй день Летнего ТехФеста

На площадке Nexign был максимально инженерный день. Ни грамма AI, только бэкенд, цифры и оптимизация. Слушали два доклада про экономику кода и производительность, а потом разбирали реальные кейсы на живом круглом столе.

Смотри влог, чтобы погрузиться с головой в этот вечер.

P.S. В нашем TG-канал рассказываем о технических мероприятиях и конференциях, делимся выступлениями экспертов, обсуждаем подборки на технические и ИБ темы.

Коннекторы 1С: быстрая интеграция через OData в Digital Q.Integration

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

На вебинаре эксперты компании «Диасофт» расскажут, как организовать обмен данными между 1С и внешними системами с помощью готового коннектора платформы Digital Q.Integration, реализованного на базе протокола OData. Вы узнаете, какие подходы для интеграции с 1С существуют, почему именно OData выбран в качестве технологической основы решения и какие преимущества это дает при построении современных интеграционных процессов.

Во время демонстрации покажем, как:

• настроить подключение к 1С с помощью коннектора Q.Integration;

• получать данные из 1С;

• добавлять/изменять данные в 1С;

• автоматизировать интеграционные процессы средствами платформы Digital Q.Integration.

Программа

13:00 – 13:10 Введение. Почему интеграция с 1С остается актуальной задачей и какие подходы используются для ее реализации.

13:10 – 13:25 Подходы к интеграции с 1С. Рассмотрим основные способы организации обмена данными, сравним интеграцию через OData и использование специализированных конфигураций 1С, разберем преимущества и ограничения каждого подхода.

13:25 – 13:40 Коннектор 1С в Digital Q.Integration. Расскажем, как реализован коннектор, какие процессы автоматизированы, как устроена работа с OData и какие возможности получает пользователь при настройке интеграции.

13:40 – 13:55 Практическая демонстрация. Покажем настройку коннектора, получение данных из 1С и изменение.

13:55 – 14:00 Вопросы и ответы. Ответим на вопросы участников и обсудим практические кейсы использования коннектора.

Кому полезен вебинар:

• ИТ-директорам и техническим руководителям;

• архитекторам интеграционных решений;

• руководителям проектов цифровой трансформации;

• разработчикам и интеграторам;

• специалистам по сопровождению корпоративных информационных систем.

Спикеры:

• Виктор Овчинников, руководитель продукта Digital Q.Integration компании «Диасофт»

• Андрей Даниленко, ведущий разработчик MSA департамента «Цифровые решения» компании «Диасофт»

Зарегистрироваться на мероприятие можно по ссылке

Эксперт «Диасофт» примет участие в круглом столе IT-World «Почему хорошие системы плохо работают вместе?»

6 августа 2026 года в 16:00 IT-World проведет круглый стол «Почему хорошие системы плохо работают вместе?». В нем примет участие Дмитрий Гаврин, заместитель директора департамента «Цифровые решения» и один из авторов блога компании «Диасофт» (Как 30 лет боли в интеграции привели нас к собственной платформе)

О чем будут говорить спикеры:           

• Почему интеграции остаются одной из самых болезненных зон корпоративного ИТ-ландшафта?

• Что чаще ломает взаимодействие систем - слабые API, разные модели данных, отсутствие владельца процесса или спешка внедрения?

• Как оценивать API-зрелость решения до покупки: документация, версионирование, песочница, ограничения, поддержка изменений?

• Как меняется ответственность поставщика ИТ-решения, если его продукт становится частью большого корпоративного контура?

• Что должно происходить с интеграциями при обновлении продукта, смене версии или доработке соседней системы?

• Почему единые справочники и мастер-данные остаются проблемой даже там, где уже есть MDM, НСИ или корпоративная шина?

• Где проходит граница между быстрой автоматизацией и архитектурным долгом, который потом мешает масштабировать решение?

• Какие требования к интеграциям, API, данным и поддержке стоит включать в ТЗ, договор и критерии выбора поставщика?

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

Регистрация по ссылке

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

Я написал бота @RemKartBot, вы можете использовать его для своего ремонта (с компа или с телефона), мои пункты я оставил для примера (вверху есть кнопка "очистить лист"). Клик по статусу задачи изменяет его на "в процессе" и "готово" и сворачивает более компактно (по клику можно опять увидеть полную версию). Короче, я сохранил своего бота, как обычный диалог в телеге, накидываю туда идеи, как в записную книжку, а в спокойной обстановке открываю карту (там прямо кнопка в чате всегда есть) и уже по пунктам оркестрирую всё, что происходит.

Карта помнит именно ваш ремонт, так что авторизовываться никак не нужно (данные хранятся в моём же блоге, а карта узнаёт вас по телеге). Можно выгрузить свою карту, переслать кому-то, загрузить (кнопки есть вверху). Дизайнеры интерьеров могут прикладывать к своим проектам такую карту, человеку будет сильно легче охватить вниманием весь процесс и понять, с чего вообще начать, что не забыть, что купить заранее, что уточнить у строителей, и плюс - она всегда под рукой. Пользуйтесь, кому полезно - @RemKartBot.

Ну и заглядывайте в Министерство Эргономики, конечно.

Где бэкенд начинает тормозить: 18 открытых уроков по языкам, данным и архитектуре

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

В августе и сентябре преподаватели OTUS проведут бесплатные уроки для бэкенд‑разработчиков. В программе — Python, Go, C# и JVM, микросервисная архитектура, PostgreSQL, брокеры сообщений, наблюдаемость и контейнеризация. Выбирайте свою тему и присоединяйтесь к практическим разборам.

Архитектура и взаимодействие сервисов

• 3 августа, 20:00. «Использование брокера сообщений Apache Kafka в распределённых очередях». Записаться

• 4 августа, 20:00. «Секреты межсервисных запросов: как сделать приложение быстрым и надёжным». Записаться

• 12 августа, 20:00. «Паттерны отказоустойчивости и масштабируемости микросервисной архитектуры». Записаться

• 13 августа, 20:00. «Управление данными в MSA — дыра в бюджете или актив для ИИ-трансформации?». Записаться

• 19 августа, 20:00. «Монолит или микросервисы? Руководство для архитекторов, которые ценят свои нервы». Записаться

• 24 августа, 20:00. «Основные шаблоны проектирования в системном дизайне». Записаться

Языки, память и конкурентность

• 3 августа, 20:00. «Go: управляем памятью как профи. Массивы, слайсы и мапы». Записаться

• 4 августа, 20:00. «Многозадачность в Python. Асинхронность, процессы, потоки». Записаться

• 5 августа, 20:00. «Битва нативных платформ: Spring Boot 4, Quarkus, Micronaut, KMP, Go и Rust». Записаться

• 18 августа, 20:00. «Python asyncio: gather, wait, TaskGroup на практике». Записаться

• 18 августа, 20:00. «Горутины и каналы: базовые принципы параллелизма в Go». Записаться

• 18 августа, 20:00. «Архитектурные ошибки, которые совершают даже опытные C#-разработчики». Записаться

Базы данных и работа с состоянием

• 11 августа, 20:00. «Работа с SQLAlchemy и Alembic в FastAPI». Записаться

• 19 августа, 20:00. «PostgreSQL на стероидах: большие данные, высокие нагрузки и масштабирование без боли». Записаться

• 1 сентября, 20:00. «PostgreSQL 18: асинхронный I/O и io_uring на практике». Записаться

• 16 сентября, 20:00. «Темпоральные данные в PostgreSQL 18: история и версии без триггеров». Записаться

Наблюдаемость и контейнеризация

• 4 августа, 20:00. «OpenTelemetry — наблюдаемость на блюдечке». Записаться

• 20 августа, 20:00. «Docker для Python-разработчика». Записаться

Что почитать перед практикой

1. Создаём HTTP/2-сервер на C++ и хостим на нём свой сайт
   _{Путь от чтения RFC и реализации обработчика запросов до запуска сервера в контейнере. Внутри — защита исполняемого файла, ограничения для HTTP/2, работа с облачными площадками и поиск утечки памяти в OpenSSL.}

2. std::expected в C++23: гайд по миграции с исключений на функциональный error handling
   _{Как сделать ошибку явной частью сигнатуры функции, выстраивать цепочки операций и постепенно внедрять std::expected в существующий проект.}

3. Move-семантика в C++: пять задач, в которых легко ошибиться
   _{Разбор ловушек, которые успешно компилируются, но приводят к лишним копированиям, замедлению программы или неопределённому поведению.}

4. Миграция на Spring Boot 4 и Java 25: пошаговый план, чтобы обновиться и не уронить прод
   _{План обновления рабочего сервиса с промежуточными этапами, автоматизированными проверками, канареечным развёртыванием и заранее подготовленным сценарием отката.}

Backend без хрупких интеграций: 5 материалов, которые вы могли пропустить

На старте проекта многие решения выглядят простыми: сделать REST API, разнести сервисы, добавить очередь, договориться о моделях данных. Но по мере роста системы выясняется, что именно эти решения определяют, насколько легко её развивать дальше.

Эта подборка будет полезна тем, кто проектирует backend‑системы, работает с API, микросервисами, доменной моделью или просто регулярно сталкивается с вопросом: «как сделать так, чтобы архитектура не мешала разработке через полгода».

Собрали 5 материалов по теме:

1. Как фронтенд получает данные с сервера: лучшие практики 2026 
   _{О том, как backend и frontend договариваются через API, где уместны REST, GraphQL, BFF и Server Components, и почему «быстро отдать JSON» ещё не значит сделать удобный интерфейс для клиента.}

2. Domain‑Driven Design: полный гайд по моделированию домена в 2026 году
   _{Разбор DDD как способа управлять сложностью: единый язык, ограниченные контексты, агрегаты, сущности и границы между частями системы.}

3. REST API: гайд по проектированию от принципов до боевых кейсов
   _{Практика проектирования API: ресурсы, методы, статус‑коды, ошибки, версионирование, кэширование и документация без формального следования REST ради REST.}

4. Как построить надёжный обмен сообщениями в микросервисах: лучшие практики для enterprise
   _{Материал про асинхронное взаимодействие, очереди, события, идемпотентность, DLQ, мониторинг и типовые проблемы микросервисных интеграций.}

5. Архитектурные решения в backend: 5 практических приёмов
   _{О том, как принимать архитектурные решения без преждевременного усложнения: модульный монолит, YAGNI, порты и адаптеры, ADR и C4-диаграммы.}

А если хотите не только читать, но и разбирать темы с практиками, смотрите дайджест — там собраны бесплатные открытые уроки по разработке, архитектуре и инфраструктуре.

Порядок сообщений, DLQ, graceful shutdown, spike нагрузки — на каждый вопрос есть минимум два рабочих ответа

Витя Михайлов, Backend Lead Garage Eight, и Женя Янченко, руководитель разработки и автор тг-канала @jane_yanchenko, разобрали 5 вопросов про брокеры со стороны RabbitMQ и Kafka соответственно.

Вопрос 1. Как вы обеспечиваете порядок сообщений, когда это критично для бизнес-логики? Например, событие «покупка товара» не должно обработаться раньше события «счет пополнен».

RabbitMQ:

• Только один консьюмер на очередь.

• Ack( ) только после завершения бизнес-логики.

• Если используешь nack — убедись, что тип очереди не quorum: он меняет логику requeue.

• Publish только строго с confirmation mode, и обработчиком connection.blocked, чтобы FlowControl не испортил нам порядок (выключить его нельзя).

— Витя

Kafka:

Kafka обеспечивает порядок в рамках одной партиции. Партиция определяется по ключу: все сообщения с одинаковым ключом попадут в одну партицию.

Например, если выбрать ключом ID заказа, все события по нему попадут в одну партицию.

Нюансы:

• определенные настройки ретраев продюсера могут привести к нарушению порядка

• изменение числа партиций может сломать прежнее распределение

— Женя

Вопрос 2. Что делать с сообщением, которое консьюмер не может обработать уже 10 раз подряд? Стратегии retry, DLQ, алертинг — как это устроено на практике.

RabbitMQ:

Сначала понять: можно ли вообще обработать сообщение? Битый JSON или некорректные данные — повторные попытки бессмысленны. Отправляем в DLX или дропаем с записью в лог.

Если обработать можно — два варианта:

1) Ретраить бесконечно (осторожно: poison message handling). Нужен мониторинг и rate limit на повторы.
2) Отбросить в DLQ, но тогда теряем порядок обработки.

— Витя

Kafka:

Заводим отдельный топик — Dead Letter Queue (DLQ).

1) Пробуем обработать сообщение. Успех — коммитим оффсет.
2) Ошибка — ретраим N раз. Помогает при временных сбоях (БД не ответила), но не при битом сообщении.
3) Попытки исчерпаны — отправляем в DLQ в исходном виде + пишем в лог.
4) Сообщения в DLQ анализируются вручную.

Вопрос 3. Как обеспечить обратную совместимость схемы сообщений при обновлении сервиса? Продюсер и консьюмер деплоятся независимо — как не сломать друг друга.

RabbitMQ:

Нельзя. Ломать. Обратную совместимость.

Миграция работает так: в какой-то момент поддерживаешь обе схемы параллельно, затем выключаешь старую. Хороший пример с тремя реальными сценариями миграции — официальный гайд RabbitMQ по переходу с classic на quorum queues.

— Витя

Kafka:

Схема сообщений в топике — публичный контракт, как в REST API. Изменения проектируем так, чтобы обе версии какое-то время работали параллельно.

Безопасно:
Добавить необязательное поле, добавить поле с дефолтом, перестать использовать поле (но не удалять).

Опасно:
Переименовать, изменить тип, удалить обязательное поле, поменять смысл.Для валидации схем — Schema Registry (особенно при Avro или Protobuf).

— Женя

Ответы от ребят на еще два вопроса ждут в нашем канале.

Бэкенд без слепых зон: 10 открытых уроков для разработчиков

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

Собрали бесплатные открытые уроки для бэкенд‑разработчиков разных стеков. Преподаватели‑практики покажут рабочие подходы, разберут типовые ошибки и ответят на вопросы. Заодно можно познакомиться с экспертами и проверить формат обучения OTUS.

Архитектура и взаимодействие сервисов

• 22 июня, 20:00. «OAuth 2.0, JWT и коварные куки: проектируем безопасную аутентификацию». Записаться

• 24 июня, 20:00. «RabbitMQ против Kafka — что выбрать для вашей структуры: сравнение и лучшие практики». Записаться

• 24 июня, 20:00. «Отказоустойчивый и высокодоступный кластер RabbitMQ». Записаться

Java и Spring

• 22 июня, 20:00. «Контейнеризация Java-приложений с Docker». Записаться

• 29 июня, 20:00. «Как работает @Transactional в Spring: границы транзакций и типовые ошибки». Записаться

• 1 июля, 20:00. «Алгоритмическая сложность коллекций в Java». Записаться

• 22 июля, 20:00. «DAO на Spring JDBC». Записаться

.NET и Go

• 18 июня, 20:00. «Хостинг ASP.NET Core изнутри». Записаться

• 25 июня, 20:00. «Кеширование в ASP.NET Core: от IMemoryCache до Redis». Записаться

• 8 июля, 20:00. «Чистая архитектура на Go без "карго-культа": слои, DTO и интерфейсы». Записаться

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

Больше бесплатных открытых уроков по другим направлениям смотрите в нашем дайджесте.

На сайте Hacker News завязалось любопытное обсуждение. Пользователь поделился опытом: в крошечной базе данных на 15 тысяч записей случилась коллизия UUIDv4. Приложение генерировало идентификаторы через uuid, популярный пакет npm, база имела ограничение UNIQUE, и однажды новая запись пришла с тем же UUID b6133fd6-70fe-4fe3-bed6-8ca8fc9386cd, что уже лежал в таблице с прошлого года.

Если что, то в этом плане у UUID должен быть полный иммолейт импрувед: вероятность такого события крайне мала. У 128-битного UUIDv4 122 случайных бита, то есть шанс попадания нового UUID в один из уже 15 000 существующих равен примерно один к 3,5 × 10³². Это какие-то проблемы с генератором псевдослучайных чисел, что сразу же расписали в комментариях к посту на HN. В ходе обсуждений сам автор истории признался, что вообще-то раньше на проекте UUIDv4 генерировались на устройстве пользователя, и уже потом эту часть логики перенесли с клиента на сервер.

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

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

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

Если тесты есть, а уверенности в них нет — 10 открытых уроков по тестированию (апрель‑май)

Тестирование в 2026 — это уже давно не только про «проверить, что работает». Это про архитектуру тестов, нагрузку, интеграции и всё чаще — про работу с AI.

Чувствуете, что текущего инструментария уже не хватает (или просто хочется систематизировать практику)? Собрали серию открытых уроков по тестированию — от базовых вещей до более инженерных подходов.

🔥 Что будет:

⓵ 28 апреля 20:00. «Первый нагрузочный тест в Apache JMeter»
_{открытый урок курса «Нагрузочное тестирование»}

⓶ 28 апреля 20:00. «Архитектура тестового фреймворка: от хаоса к стабильности»
_{открытый урок курса «Автоматизатор тестирования на Python»}

⓷ 28 апреля 20:00. «Контрактные тесты в Kotlin: как подружить фронт и бэкэнд»
_{открытый урок курса «Автоматизатор тестирования на Kotlin»}

⓸ 29 апреля 20:00. «Качество C#‑кода: от модульных тестов к системному подходу»
_{открытый урок курса «C#-разработчик. Продвинутый уровень»}

⓹ 7 мая 20:00. «Тестирование микросервисов на Go: почему ваш сервис ломается под 1000 RPS»
_{открытый урок курса «Микросервисы на Go»}

⓺ 19 мая 20:00. «Навыки нагрузочного тестирования и их роль в развитии инженера»
_{открытый урок курса «Нагрузочное тестирование»}

⓻ 19 мая 20:00. «Введение в OpenTelemetry и основы наблюдаемости»
_{открытый урок курса «C#-разработчик. Продвинутый уровень»}

⓼ 21 мая 20:00. «Суперсилы Kotlin для удобных UI‑автотестов»
_{открытый урок курса «Автоматизатор тестирования на Kotlin»}

⓽ 21 мая 20:00. «ИИ как ассистент QA: пишем API‑тесты с нуля»
_{открытый урок курса «Автоматизатор тестирования на Python»}

⓾ 21 мая 20:00. «API Gateway и не только: шаги к идеальной архитектуре внешних API»
_{открытый урок курса «Архитектор программного обеспечения»}

Подборка получилась разнообразной — и это как раз полезно. Можно точечно закрыть конкретный пробел: разобраться с нагрузочным тестированием, контрактами, API‑тестами или архитектурой фреймворка. А можно посмотреть шире — как меняется роль QA, когда тестирование всё теснее связано с разработкой, архитектурой, наблюдаемостью и AI‑инструментами.

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

📌 Посмотрите каталог курсов по тестированию: там уже не отдельные инструменты, а полноценные треки с практикой, архитектурой и реальными кейсами.

[Перейти в каталог]

Бэкенд «тормозит», API ломаются, а архитектура трещит: уроки, которые помогают закрыть эти проблемы

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

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

• 22 апреля 20:00. Bun + ИИ: создаём быстрый сервер нового поколения на JavaScript

• 22 апреля 20:00. Symfony Workflow: конечный автомат для реализации бизнес-логики

• 23 апреля 20:00. Многопоточность в C++: как писать быстрые и безопасные приложения

• 23 апреля 20:00. Паттерны RESTful API. Как проектировать удобные, масштабируемые и гибкие API?

• 28 апреля 20:00. Фоновые задачи в Django: работа с Celery

• 30 апреля 20:00. Поиск в базе знаний: где векторы ошибаются, а графы помогают

• 4 мая 20:00. Интерфейсы в Golang изнутри

• 5 мая 20:00. Postgres + JSON: реляционная мощь, документная гибкость

• 5 мая 20:00. Архитектурные решения в бэкенд-разработке

• 6 мая 19:00. Разработка проекта на Kotlin: коллаборация человека, архитектурных шаблонов и ИИ-команды

• 6 мая 20:00. Rust в деле: пишем многопользовательский чат с сервером, клиентом и CLI

• 7 мая 20:00. От кода до Kubernetes за полтора часа

• 7 мая 20:00. Тестирование микросервисов на Go: почему ваш сервис ломается под 1000 RPS

• 13 мая 20:00. Kafka Streams DSL

• 13 мая 20:00. ClickHouse для аналитики больших данных: практические кейсы и связь с NoSQL-экосистемой

• 14 мая 20:00. Взаимодействие с базой данных и миграции на Go

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

Конец микросервисного угара: как Amazon, Uber и Netflix внедряли монолиты

Весной 2023 года Prime Video (Amazon) выкатил кейс, который для многих стал страшным сном: они слили красивую микросервисную оркестрацию и снизили стоимость инфраструктуры более чем на 90%.

Что они сделали? Перестали гонять данные через S3 между десятком серверлесс-функций ради банальной обработки видео. Они собрали те же самые компоненты (медиаконвертер, детекторы) в один контейнер. Вызов функции в памяти оказался быстрее и на порядок дешевле, чем "облачная магия".

Шок-контент? Только для тех, кто перечитал умных книг. Остальные просто кивнули.

Скрытый налог, о котором не пишут в книжках

Мы все прочитали «Чистую архитектуру» и умеем рисовать квадратики. Мы научились резать монолиты вдоль и поперек. Но в лучших практиках почему-то обходят главный вопрос: во что это реально обходится бизнесу?

Распределенные системы — это не бесплатный апгрейд. Это класс расходов, которого физически нет в монолите.

Вы платите за:

1. Пересылку данных по сети вместо вызова method() в памяти.

2. Отладку ада, когда для исследования бага нужно поднять логи 7 разных сервисов.

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

В итоге мы получаем внешне технически совершенную систему, которую никто не может окупить. Бывает, что переход в микросервисы — это не инженерное решение, а следование вере.

Опыт Uber

У тебя 5 сервисов — ты держишь их в голове. У тебя 500 сервисов — ты не инженер, ты -- смотритель в зоопарке.

В 2016 году в компании Uber поймать баг означало пройти по 50 сервисам из 12 разных команд. Инженеры тратили больше времени на синхронизацию в слаке, чем на написание кода.

Решение Uber (DOMA) для многих стало интересным: они не стали переписывать код в монолит. Они сгруппировали этот зоопарк по реальным доменам и прикрыли их общими шлюзами.

Монолит 2.0: как было в Netflix

В 2012-м Netflix тушил каскадные отказы через Hystrix. Но для длинных бизнес-процессов (прием контента, кодирование, раскатка по CDN) это было как пластырь на переломе. Инженеры собирали логи руками.

В 2016-м они выкатили решение Conductor — оркестратор. По сути, это монолитный движок с UI для визуализации потоков своих микросервисов. В Netflix не побороли сложность, а переупаковали её. Теперь им нужна отдельная команда, чтобы поддерживать монолит который оркестрирует микросервисы.

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

• Может ли одна команда выкатить фичу без согласования с пятью другими? Если для баг-фикса нужна координация 10+ команд — границы проведены неверно. Вы строите самый худший в мире архитектурный паттерн: распределенный монолит. Вы получите все минусы микросервисов и все минусы монолита одновременно.

• Какая доля бюджета уходит на бизнес-логику, а какая — на то, чтобы сервисы могли просто "договориться"? Готовы ли вы содержать сложный слой оркестрации (как Prime Video) только ради того, чтобы система технически работала?

• Есть ли у вас цифры, по которым вы поймете, что архитектура перестала окупаться? Prime Video начали с серверлесса и слепили всё в один процесс под реальной нагрузкой.

Выводов не будет, вы сделаете их сами.
Послушать расширенную версию статьи как сказку на ночь без донатов и рекламы можно на Яндекс.Музыке, Звуке и Apple Podcasts.

tg https://t.me/i_am_analyst

Установка, настройка и использование NATS 

Брокер сообщений для микросервисов — звучит страшно, но только пока не разберешься. NATS написан на Go, запускается за минуты и не требует сложной инфраструктуры. 

В блоге разобрали, как установить NATS на Linux и Windows, настроить аутентификацию, TLS и JetStream — и сразу проверить всё это из консоли. 

Читайте полный разбор на сайте Рег.облака.

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

С некоторым опозданием предлагаем вам почитать обзор на переведённую нами книгу Диего Пачеко и Сэма Сгро "Принципы модернизации программных архитектур". Обзор сделали в своём корпблоге специалисты дружественной нам компании SSP-Soft. Книга появилась в продаже в начале декабря, пока только бумажная версия.

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

Приятного чтения!

Многие используют подход API First в проектировании систем, но зачастую даже не задумываются, что порождают таким образом сервисы с анемичными доменными моделями, проектируя по сути REST-обертки над базой данных с отсутствием какой-либо бизнес-логики.

API First и Богатая доменная модель не являются взаимоисключающими понятиями, если правильно выстроить процесс и архитектуру.

Главная проблема: API First фокусируется на контрактах внешнего мира, что часто приводит к созданию DTO/Model классов, которые являются чистыми структурами данных без поведения (анемичная модель).

API First — это про контракты, а не про реализацию. Не позволяйте инструментам кодогенерации диктовать структуру вашей доменной модели!

Правильный workflow:

1. API Design First: Создайте/обновите OpenAPI спецификацию.

2. Генерация DTO: Сгенерируйте или создайте классы для API‑контрактов.

3. Projection First: Спроектируйте доменную модель независимо от DTO, фокусируясь на поведении и инвариантах.

4. Создание Mapping Layer: Напишите преобразователи между DTO и Domain Objects.

5. Реализация Application Service: Тонкий слой, который координирует работу домена.

Стек технологий, который помогает:

— MapStruct: Для автоматизации маппинга между DTO и Domain
— JUnit 5: Для тестирования доменной логики
— OpenAPI Generator: Для автоматической генерации DTO из спецификации
— ArchUnit: Для проверки архитектурных правил (например, запрет на анемичные модели)

// ArchUnit тест, проверяющий, что в доменных классах есть поведение
@ArchTest
static final ArchRule domain_models_should_have_business_methods = 
    classes()
        .that().resideInPackage("..domain..")
        .and().areAnnotatedWith(Entity.class)
        .should().containAnyMethodsThat(
            DescribedPredicate.describe(
                "have business methods", 
                method -> !method.getName().startsWith("get") && 
                         !method.getName().startsWith("set")
            )
        );

Приглашаем на бесплатный вебинар «Микросервисы: 5 главных ошибок и как их избежать с самого начала». Обсудим, какие ошибки возникают при переходе на MSA: от не тех границ сервисов до хаоса и технического долга. Вы узнаете, как с самого начала проектировать архитектуру правильно и получите чек-лист «10 признаков здоровой микросервисной системы» чтобы не создать «распределенный монолит».

‼️ Обратите внимание, что чек-лист будет выдан только участникам эфира.

🕓 Когда: 25 ноября, 16:00–17:00 (Мск)

👨‍🎓 Спикер: Бурцев Николай — cпециалист по архитектуре ПО, проектированию MSA, .NET-разработке.

Разберём:

1️⃣ Неправильное выделение границ микросервисов: бизнес-декомпозиция против технической.

2️⃣ REST-зависимость: когда API превращается в паутину.

3️⃣ «Всё через брокер»: когда Kafka и RabbitMQ создают больше проблем, чем решают.

4️⃣ Архитектура без инфраструктуры: CI/CD, наблюдаемость, DevOps-влияние.

5️⃣ Архитектура без коммуникации: стандарты, код-ревью, управление качеством.

👉 Записаться

Пошаговый гайд по работе с RabbitMQ

RabbitMQ — брокер распределенных сообщений, разработанный на основе стандарта AMQP (Advanced Message Queuing Protocol). Этот инструмент собирает потоковые данные из нескольких источников, после чего распределяет и маршрутизирует их для дальнейшей обработки. Выбираем брокер сообщений и подробнее знакомим с его возможностями.

Бенефиты RabbitMQ, которые выделяют его на фоне других похожих сервисов: 

• надежность — все сообщения в RabbitMQ будут доставлены с соблюдением порядка, даже в случае технический сбой;

• масштабируемость — может работать с большими объемами данных. Также его можно развернуть не только на отдельном сервере, но и в распределенной среде;

• гибкость — поддерживает большое количество сценариев для маршрутизации и распределения сообщений. Это позволяет сочетать программу со многими приложениями.

Как настроить RabbitMQ на трех операционных системах: Ubuntu, Debian и CentOS Stream, а также об основных принципах работы этой технологии — читайте в подробном гайде в базе знаний Рег.облака.

Рецепт приготовления кролика от нашего Backend Lead U^ｪ^U

Брокеры сообщений, в частности RabbitMQ, широко применяются во всем IT. Однако это далеко не магическая коробка, а написать код так, чтобы не потерять свои сообщения — крайне нетривиальная задача.

Этим летом наш Backend Lead Витя Михайлов выступил на Saint HighLoad++ 2025, где рассказал, как же правильно готовить RabbitMQ, и поделился классными кейсами.  

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

Тестируем микросервисное приложение с кучей интеграций — четыре совета из практики  

На одном из финтех-проектов наша команда тестирования столкнулась с серьезными вызовами: нестабильные партнерские API, отсутствие тестовых сред у партнеров, лимиты на запросы и риски всё сломать одним обновлением.

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

🛠️ Внешние сервисы без тестовых контуров

Решение: собственный мок-сервис на основе WireMock.

Как он работает:

• тестировщик задает нужный ответ и отправляет его через HTTP-запрос в БД;

• нужные вызовы подменяются в конфигурации;

• при тестировании запрос уходит не во внешний API, а в мок, который отдает нужный ответ.

Моки у нас кастомные, конфигурируются через Swagger, и не завязаны напрямую на CI/CD — это упрощает запуск и дает гибкость.

Плюс: так мы не зависим от внешних API, которые то работают, то нет.

💸 Платные вызовы и лимиты на тестовые запросы

Решение: изолированные стенды и замещение моками везде, где возможно.

Если API-партнер дает 150 вызовов в месяц, а вам нужно 500 на автотесты — моки опять же спасают. Мы блокируем обращения к реальным API на командных стендах и заменяем их заглушками. Проверку живых интеграций оставляем только на пред-проде.

Плюсы:

• не сжигаем бюджет;

• эмулируем ошибки и нестандартные ответы;

• ускоряем тесты без зависимости от внешней стороны.

🔄 Нестабильность интеграционных тестов

Решение: изоляция и моки как защитный слой.

Микросервисная архитектура — это боль, когда один упавший сервис ломает релиз. Поэтому мы:

• эмулируем нестабильные вызовы моками;

• изолируем свою часть и фокусируемся на ее стабильности;

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

🤝 Десятки команд, завязанных на общий процесс

Решение: интеграционные проверки и ревью на совместимость.

Когда много команд делают один продукт, любое изменение может зацепить чужой модуль. Мы выстроили систему так, чтобы ошибки ловились до мерджа, а не после инцидента. Что помогло:

• общие тестовые фреймворки и единый подход к интеграционным тестам;

• сценарии, которые включают зависимости от других команд;

• проверка обратной совместимости: если что-то ломает чужой функционал — фича не проходит MR.

Подробнее о каждом из подходов читайте в статье QA-инженера AGIMA Святослава Волохова.