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

В этой статье я разбираю четыре основных стиля интеграции: передача файлов, общая база данных, удалённый вызов процедур (RPC) и асинхронный обмен сообщениями (Messaging). Без воды, на реальных примерах — включая историю провала TSB Bank, который стоил сотен миллионов фунтов.

Вы узнаете:

▪️ почему общая база данных — это антипаттерн для микросервисов;
▪️ как асинхронность спасает прод, когда падают соседние сервисы;
▪️ какие best practice используют команды, чтобы не получить распределённый монолит.

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

Проектируете REST API и всё ещё используете 200 OK для ошибок?

А знаете, почему неправильные статус-коды могут убить производительность и как всего один кейс с TSB Bank показал цену плохого анализа?

В этой статье разбираем реальные принципы REST, модель зрелости Ричардсона.Полезно всем, кто пишет бэкенд или проектирует микросервисы.

Продолжаем серию «Kotlin для новичков»!

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

В этом туториале вы узнаете:

▪️ Как объявлять функции и чем это отличается от Java.
▪️ Что такое именованные аргументы и значения по умолчанию (и почему это круто).
▪️ Как работает стек вызовов и области видимости.
▪️ Главные best practices, которые используют в разработке.

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

Когда бизнес-логика становится сложной, микросервисы из удобного инструмента превращаются в источник боли. Классические «сценарии транзакций» приводят к монструозным классам и распределённым транзакциям, которые невозможно поддерживать.

В этой статье разберу, как DDD и агрегаты помогают проектировать бизнес-логику так, чтобы она не разваливалась под нагрузкой. Покажу на реальном примере HR-сервиса:

▫️ почему объектные ссылки между сервисами — зло;
▫️ как одно правило «транзакция = один агрегат» меняет архитектуру.

Продолжаем серию «Kotlin для новичков»! Сегодня разбираем самое сердце любого кода — управляющие конструкции: if, when, for, while.Вы узнаете, почему if в Kotlin — это не просто оператор, а выражение, как when заменяет целые лесенки else-if, и чем for по диапазонам лучше классического цикла. Реальные примеры и лучшие практики и история о том, как мы отрефакторили 300 строк спагетти-кода в 80 строк с помощью when и диапазонов. Читайте, чтобы писать чистый и понятный код на Kotlin.

Разрабатываете микросервисы и чувствуете, что бизнес-логика превращается в хаос?

В статье на примере простого UserService разберем, как три правила агрегатов DDD и асинхронные доменные события помогают навести порядок.

Обсудим, почему нельзя хранить объектные ссылки между сервисами, как спроектировать агрегат на Spring Boot

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

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

▪️ чем отличаются тестовые условия от тест-кейсов,
▪️ зачем нужны таблицы решений и попарное тестирование,
▪️ как мониторинг и контроль помогают в общем процессе,
▪️ почему ретроспектива тестирования так же важна, как и планирование.

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

Даже опытные руководители пасуют перед сложными разговорами. Мы молчим, когда сотрудник делает что-то не так. Терпим, надеемся, что «само рассосётся». А потом удивляемся, почему команда живёт в стрессе, а люди уходят, так и не узнав, что от них хотели.

В этой статье — только практика:

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

Статья будет полезна начинающим и практикующим тимлидам, а также разработчикам, которые планируют переход на руководящую позицию.

Вы только что стали тимлидом? Поздравляю. А теперь вопрос: вы ещё пишете код или уже управляете людьми? Если второй вариант, а в голове всё ещё «я сделаю быстрее сам» — вы в ловушке.

В этой статье:

‣ разбираю, почему делегирование — главный навык руководителя, как не скатиться в микроменеджмент и вырастить команду, которая справится без вас;

‣ даю пошаговый алгоритм, матрица зрелости задач, реальный кейс и схемы.

Материал будет полезен для тех, кто хочет перестать быть «главным исполнителем» и начать управлять результатом

Когда команда пишет API, но документация живёт своей жизнью, а интеграторы часами гадают, что значит ошибка 500, — проект неизбежно тонет в хаосе. В этой описан подход, который является лучшим решением: Design‑First на основе OpenAPI.

Мы пройдём полный цикл: от проектирования спецификации до работающего Spring‑приложения с автоматической генерацией кода и централизованной обработкой ошибок.

Вы узнаете, как одна команда ./gradlew clean build может создать модели и интерфейсы, избавив вас от рутины.

Выкатили приложение, а через час — таймауты? Redis отключился, а вы узнали об этом от клиентов?

В этой статье на реальном примере покажу, как Spring Boot Actuator превращает ваше приложение из «чёрного ящика» в прозрачную систему. Разберём:

➡ Что такое Actuator и зачем он нужен.
➡ Как настроить эндпоинты, чтобы не открыть дыру в безопасности.
➡ Какие метрики реально помогают найти узкие места (история, как мы ускорили приложение на 40%).
➡ Кастомные метрики для бизнес-показателей.
➡ Лучшие практики продакшена: liveness/readiness probes, изоляция портов, кастомные HealthIndicator.

Индексы есть, а запросы всё равно тормозят? Или наоборот — индексов слишком много, и они только увеличивают нагрузку на запись?

Многие разработчики и администраторы баз данных попадают в ловушку: ставят B-Tree на всё подряд и надеются на лучшее. Но в highload-системах это может привести к катастрофе.

В этой статье я делюсь реальным опытом работы с PostgreSQL.

Статья будет полезна разработчикам, архитекторам и администраторам, которые хотят не просто «поставить индекс», а понять, как работает PostgreSQL под капотом и как проектировать базы данных, выдерживающие миллионы запросов в секунду.

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

В статье вы найдёте:

▫️ живые примеры из реальных аварий (включая историю с бесконечными ретраями в очереди),
▫️ три готовые диаграммы в формате Mermaid, которые можно сразу использовать в документации,
▫️ чёткий алгоритм выбора стиля под вашу задачу.

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

Продолжаем серию статей для тех, кто начинает изучать Kotlin с нуля. Во втором уроке детально разбираем фундамент языка:
▪️Неизменяемые (val) и изменяемые (var) переменные
▪️Базовые типы: Int, Double, String, Boolean, Char
▪️Строковые шаблоны и многострочные строки
▪️Арифметические операции, целочисленное и вещественное деление
▪️Преобразование типов (явное и неявное)
▪️Ввод данных с консоли через readln()
▪️Символы и Unicode (коды символов)
▪️Особенности остатка от деления с отрицательными числами
▪️Инкремент и декремент (префиксная и постфиксная формы)

Все примеры кода — из реальной практики, доступны в открытом репозитории на GitHub (ссылка в статье). Материал подготовлен на основе опыта преподавания в OTUS и работы в FinTech. Статья поможет вам быстро войти в тему и избежать типичных ошибок новичков. Идеально для первого знакомства с языком или для систематизации знаний.

Как тестировать микросервисы, чтобы не было мучительно больно на проде? Разбираем пирамиду тестирования, интеграционные тесты с Testcontainers, контракты с Pact и нагрузочные испытания. Расскажу, какие практики реально работают в крупных проектах...

Git — это вызов, через который проходит каждый второй новичок в разработке. Ветки называются «asdasd», коммиты — «правки», а pull request пугает своей красной кнопкой. Знакомо?

Меня зовут Сергей Прощаев, я Tech Lead в FinTech и преподаватель на курсах в OTUS. В этой статье разбираем самое главное: как создавать ветки и почему их нельзя называть как попало, что писать в коммитах, как сделать pull request в лучших практиках команд разработки

Моделирование домена — это не про UML-диаграммы и не про красивые ER-модели. Это про то, как перестать тратить месяцы на переписывание кода и начать говорить с бизнесом на одном языке. В статье — разбор DDD без воды: Ubiquitous Language, Bounded Context, тактические паттерны (Entities, Value Objects, Aggregates) и реальный пример кода на Java. Заходите — будет практично!

Статья к открытому уроку курса QA Automation Engineer про начало разработки тестов на языке Java которая погружает в основы синтаксиса.