Про выделение микросервисов из монолита рассказывали много, но у каждого свой путь – в статье расскажем про наш.
От простейшего выделения сервиса в модуль в начале до решения проблем разрыва транзакций, SQL Join-запросов, задержек асинхронного API и непосредственно выделения нового сервиса. Использование event-driven архитектуры, редизайна модели данных и интеграционного слоя как основных подходов в процессе выделения.
Предыдущая статья: Часть 3: А при чём здесь The Thundering Herd Problem?
Thundering Herd — это о бесполезной трате CPU на пробуждение “лишних” процессов, которые не смогут выполнить работу.
Dogpile Effect — это о бесполезной нагрузке на внешний ресурс (например, БД) из-за многократного выполнения одной и той же работы.
Часть 3: А при чём здесь Thundering Herd?
В конце второй части я оставил вас с интригой: почему мой AI-ассистент решил поправить лектора и предложил термин Thundering Herd (несущееся стадо бизонов)?
Часть 2: В поисках классических проявлений Dogpile Effect.
Мое "расследование" началось с самого очевидного — поиска информации по термину Dogpile Effect. Хотелось найти каноническое определение термина Dogpile Effect.
Этим постом хочу открыть серию постов по материалам курса Архитектор ПО.
Управление репликами - как избежать проблемы Dogpile при горизонтальном масштабировании и что вообще такое Dogpile.
Предупреждение: не сомневаюсь, что наверняка кто-то, прочитав данную статью, возжелает закидать меня тапками, но это его право, я не претендую на истину.
Я начал писать эту статью около двух месяцев назад. Писал по мере возможности и уже почти закончил, как буквально на днях было обсуждение именно этой темы с коллегами. По результатам услышанных там вопросов я добавил еще пару абзацев, чтобы постараться ответить на данные вопросы в комплексе. Эта статья лежала в черновиках с декабря 2021г, я совсем про нее забыл.
В наше время каждый слышал про Web-API и у многих это ассоциируется с REST. Однако этот многострадальный REST всегда какой-то не такой, с ним все время что-то не так.
Разработчики часто спорят и упрекают друг друга, что твой REST недостаточно REST-овый. Это стало чем-то вроде культа или даже религии. Я не планирую рассказывать о том, как правильно готовить REST, но весь материал именно вокруг этого многострадального RESTа.
Один сервер — это точка отказа. Рано или поздно он не выдержит. Как только появляется второй, третий, десятый сервер, возникает вопрос: кто будет раздавать им работу? Эту роль и берет на себя балансировщик нагрузки.
Но это не тупая раздача запросов по очереди. Хороший балансировщик — это мозг. Он должен чувствовать пульс системы: какой сервер отвечает быстро, а какой начал "тормозить". Он должен понимать, что запросы одного пользователя лучше отправлять в одно и то же место. Ошибка в этой логике — и вся система превращается в хаос из ошибок и потерянных сессий.
Я PHP-разработчик с восьмилетним коммерческим опытом. Долгое время я не видел смысла в микросервисах — пока не перешёл на Python и не столкнулся с его архитектурными особенностями.
Привет! Меня зовут Денис, я руковожу группой R&D в Naumen Service Management Platform. В этой статье — разбор виртуальных потоков (VT) в Java: почему исторически обычные потоки упирались в I/O, как и зачем появились виртуальные потоки, что пошло не так в Java 21, что исправили в JDK 24–25, а также когда виртуальные потоки необходимы, а когда — лучше от них отказаться.
Всем привет. Это моя первая статья на Habr. Хочу поделиться с вами своей историей, через что я прошел, чтобы устроиться на свою первую официальную работу программиста на популярном и любимом всеми языке Python. В статье будет приведена вся статистика: названия компаний, предложенные мне зарплаты, количество откликов, количество скринингов, технических собеседований, суммарно потраченное время и, конечно, результаты проделанных трудов. Возможно, вы обнаружите много воды, но по другому статья не будет полноценной.
По тексту есть достаточно много полезных лайфхаков, которые помогли мне на этом пути. Надеюсь, вы подчерпнете что нибудь для себя.
Микросервисная архитектура при построении приложений в последние годы пользуется большой популярностью среди разработчиков. Всевозможные веб-приложения активно используют данную архитектуру. Но почему бы не попробовать использовать эту архитектуру при работе с 1С?
В этой статье мы поговорим о преимуществах и недостатках каждой из архитектур и о том, как можно использовать микросервисы при работе с конфигурациями 1С.
Около года назад я написал первую часть статьи о Single SPA — о том, как я выбирал архитектурный подход, боролся с монолитом и пробовал собрать первые микрофронтенды. В статье были разобраны базовые принципы работы Single SPA, подключение importmap, сравнение с другими архитектурными решениями и настройка сборки на Webpack и Vite.
Эта статья — продолжение цикла. Здесь я поделюсь практикой: как на самом деле живётся с Single SPA, какие есть подводные камни и что можно вынести в виде рекомендаций.
Сразу скажу: Single SPA — не «серебряная пуля» и уж точно не современный тренд фронтенд-разработки. В 2025-м появилось еще больше других подходов, которые решают похожие задачи иначе. Но Single SPA всё ещё актуален там, где есть огромные легаси-системы, которые невозможно переписать с нуля. И вот именно для таких кейсов мой опыт может быть полезен.
Статья о реализации сервиса на C++ с применением TDD, DDD и событийно-ориентированной архитектуры. Проект переносит идеи из книги «Паттерны разработки на Python: TDD, DDD и событийно-ориентированная архитектура» на C++.
Привет, дорогой читатель! Я, Владимир Зиновьев, ведущий тестировщик в ИТ-команде «Северстали». Если тебя заинтересовала эта статья, то скорее всего ты такой же тестировщик, как и я, и задаёшься вопросом, как эффективно выстроить свою работу. Здесь я поделюсь долгим путём нашей команды со всеми «шишками» и успехами тестирования наших систем в большом MES-проекте. Особенно я бы порекомендовал обратить внимание на раздел с тестированием «Legacy-системы», так как там применялись довольно нестандартные и интересные подходы, по-моему мнению, конечно. Давай погружаться.
Мир веб‑разработки давно вышел за пределы простых проектов. Статьи про «Hello, world» больше не спасают, когда нужно собирать масштабируемые приложения для реальных пользователей. Что выбрать — монолит или микросервисы? REST или GraphQL? React, Vue или Angular? Node.js, Python или Go? Какая база данных лучше подойдёт — реляционная или NoSQL? Нужно ли кэширование? Как настроить CI/CD, контейнеризацию и мониторинг? И почему нельзя забывать о мобильной версии и SEO? В этой статье я делюсь опытом, описываю архитектурные подходы, сравниваю основные технологии и инструменты, рассказываю о бэкенд‑ и фронтенд‑best practices, базах данных, кэшировании, DevOps, мониторинге и оптимизации. Каждая тема подкреплена примерами и ссылками на источники. Материал рассчитан на тех, кто хочет уверенно руководить полным циклом разработки — от планирования до продакшна. Если вы давно ищете структурированное руководство по современному фулл‑стеку, оно перед вами. Из этого путеводителя вы также узнаете об оптимизации производительности Node.js (gzip, асинхронность, логирование), работе с графами данных и типизации GraphQL, особенностях React (hooks, SSR), Vue, Angular, Tailwind и shadcn/ui, выборе баз данных, настройке кэширования Redis, задачах CI/CD и Dockerfile, Kubernetes, а также об инструментах мониторинга и SEO, включая мобильную адаптивность и структурированные данные. Текст большой, но разбит на разделы и содержит кодовые примеры, так что вы сможете легко адаптировать идеи под свои задачи.
В интернете есть книги и множество статей, таких как эта, в которых авторы приводят аргументы в пользу использования Postgres для всего. Я решил рассмотреть один из вариантов использования — применение Postgres вместо Redis для кэширования. Я довольно часто работаю с API, поэтому я создал очень простой HTTP-сервер, который отвечает данными из этого кэша. Я начал с Redis, так как часто сталкиваюсь с этим на работе, а затем переключился на Postgres с использованием нежурналируемых таблиц и посмотрел, есть ли разница.
В мире микросервисов десятки, а то и сотни сервисов живут своей жизнью. Каждый со своим адресом, своими правилами, своей аутентификацией. Для внешнего клиента это выглядит как город без улиц и указателей. API Gateway — это попытка навести порядок. Он становится единым фасадом, центральным КПП для всего вашего бэкенда.
Но эта простота обманчива. Внедрение шлюза порождает свой собственный набор сложных архитектурных проблем. Решить их неправильно — значит построить себе очень дорогую и хрупкую тюрьму.
Статья о том, какие бывают ограничения самописных планировщиков задач и как мы перевели весь процесс планирования в NiFi, сделав его более прозрачным.
Перевести CRM-систему с тысячами пользователей на полностью российский стек — звучит как вызов? Мы тоже так подумали. Но теперь можем точно сказать: это возможно, и более того — это работает.
Команда Альфа-Банка с нашей поддержкой перенесла CRM-платформу, которую используют сотрудники в отделениях по всей стране, на Axiom JDK и контейнеризовала её с помощью Axiom Runtime Container.
Высоконагруженная система ежедневно обслуживает более 20 000 сотрудников банка, работает в сотнях отделений — и всё это без внешних зависимостей и с полной технологической автономией.
Нормализация vs Денормализация: Mongo, Postgres и реальная жизнь. Почему у нас вырастает 160 таблиц там, где мог быть один jsonb? И как понять, когда денормализация — это костыль, а когда осознанный выбор?
Если при слове «нормализация» у тебя начинается зевота, а менеджер с порога предлагает «спроектировать базу» — этот текст для тебя.
