Когда компания растёт из одного продуктового направления в несколько, технический долг начинает выглядеть иначе. Проблема уже не в «старом коде», устаревших зависимостях или сложной поддержке legacy-системы. Долг начинает накапливаться в расхождении инженерных решений между сервисами.
Рубрика «микросервисы»
Технический долг — это не только legacy: как мы уменьшаем разброс решений между Go-сервисами
2026-07-07 в 13:32, admin, рубрики: golang, renovatebot, архитектура, бэкенд, микросервисы, рефакторинг, стандартизация, технический долг, управление зависимостями, шаблонизацияBackstage — управление микросервисным ландшафтом без хаоса
2026-05-31 в 13:20, admin, рубрики: backstage, CNCF, CTO, Spotify, инженерная культура, инфраструктура, масштабирование, микросервисы, портал разработчика, стандартизация разработкиПредставьте: в вашей компании уже не десятки, а сотни микросервисов. Новый разработчик приходит в команду и первую неделю тратит не на код, а на поиски. «Где лежит этот API?», «Как запустить этот сервис локально?», «Кому писать, если он падает?». Каждая команда изобретает свои велосипеды для документации, а общие инструменты превращаются в разрозненную коллекцию закладок в браузере.
Но проблема не только в онбординге. По мере роста компании растет «когнитивная нагрузка». Разработчик вынужден держать в голове десятки ссылок на CI/CD, дашборды, баг-трекеры и Wiki — вместо написания кода он переключается между контекстами.
Первый серьёзный проект на Python: Manga-Day — асинхронный парсер манги и путь к микросервисам
2026-04-20 в 5:28, admin, рубрики: python, микросервисы, первый проектПривет!
Многие из нас в какой-то момент мечтают создать «что-то своё большое». У меня такой мечтой стала система, которая сама отслеживает новинки манги на десятках сайтов и собирает всё в удобную базу. Долгое время это оставалось просто мечтой — опыта не хватало. Но после нескольких небольших пет-проектов (в частности, mini-rostics) я наконец решился и написал Manga-Day — свой первый проект на десятки тысяч строк кода.
В этой статье я расскажу, как всё начиналось, какую архитектуру выбрал, с какими проблемами столкнулся и как их решил. Надеюсь, мой опыт поможет вам быстрее пройти похожий путь.
Об проекте
HttpClient в Spring 7: замена FeignClient или нет?
2026-04-12 в 10:15, admin, рубрики: feignclient, httpclient, java, openapi, restclient, spring, spring boot, webclient, микросервисыЗа последние несколько лет для вызова внешних API в каждом втором (если не первом) проекте я видел одну и ту же картину:
-
RestTemplate -
или
FeignClient
Причём Feign почти всегда шёл в связке с OpenAPI: сгенерировали клиент, получили интерфейсы и не думаем о реализации. Удобно, красиво, привычно.
Но потом в Spring появился нативный декларативный HttpClient, который работает поверх RestClient / WebClient
И у меня возник вопрос: а можно ли им заменить Feign, не потеряв удобство?
Спойлер: да, можно и будет даже удобнее.
Откуда вообще взялся HttpClient
Идея, на самом деле, очень простая.
Читать полностью »Почему эволюция не прошла бы код-ревью: инженерный разбор гемоглобина
2026-03-31 в 8:10, admin, рубрики: god object, srp, антипаттерны, архитектура по, балансировка нагрузки, биология, гемоглобин, микросервисы, научпоп, эволюцияПредставьте, что вам на собеседовании дали задачу: спроектировать систему доставки газа по трубам переменного давления, причём система должна загружаться почти на 100% в зоне высокого давления, а разгружаться (быстро и почти полностью) в зоне низкого. Вы бы, наверное, нарисовали линейную зависимость. Больше давления — больше загрузка. Просто, и главное, что будет легко тестировать.
Эволюция посмотрела на этот вариант, подумала 500 миллионов лет и сделала всё наоборот.
Техзадание от природы
Предлагаю чуть формализовать. У нас есть два «дата-центра»:
-
ЛёгкиеЧитать полностью »
Миллиард записей и 8 Марта: как YDB спас праздник
2026-03-26 в 7:01, admin, рубрики: ydb, базы данных, высокая нагрузка, микросервисы, работа с данными, яндекс
Почему Kafka недостаточно: гарантированная доставка сообщений в распределённых системах
2026-03-20 в 5:45, admin, рубрики: ibox, outbox, гарантированная доставка сообщений, микросервисы, согласованность1. Введение
Kafka часто воспринимается как система, гарантирующая доставку сообщений и Exactly Once Semantics. Однако в реальных распределённых системах эти гарантии заканчиваются на границе брокера.
Сообщение может потеряться между записью в базу данных и публикацией события, а может быть обработано повторно при сбое сервиса.
В этой статье разберём:
-
где именно теряются гарантии Kafka
-
почему Exactly Once не работает на уровне всей системы
-
и как паттерны Outbox / Inbox помогают решить эту проблему.
2. Контекст: микросервисы и асинхронное взаимодействие
Urich: DDD и CQRS для микросервисов на Starlette без ручной раскладки роутов
2026-02-24 в 10:16, admin, рубрики: cqrs, DDD, python 3, starlette, микросервисыКогда хочется строить бэкенд по DDD и CQRS на Python, а не «просто REST», приходится самому раскладывать роуты, команды, запросы и события. Я сделал фреймворк Urich — в нём один объект описывает ограниченный контекст, а маршруты и OpenAPI получаются из этого описания. Расскажу, зачем это нужно и как выглядит в коде.
В чём проблема
FastAPI и Starlette отлично закрывают задачу «принять HTTP, провалидировать, ответить». Но они не говорят, как организовать домен: где команды, где запросы, как связать агрегаты с репозиториями и кто подписывается на события. Всё это ты проектируешь сам и вручную вешаешь на роуты.
В итоге:
Почему мы строим звездолеты для перевозки картошки
2026-02-21 в 6:32, admin, рубрики: архитектура, микросервисы, монолит, оверинжиниринг, опыт, простота, разработка, стартапыВы все это видели.
Стартап на три человека. Идея простая — агрегатор скидок в районных парикмахерских. Бэкенд еще не написан, но архитектура уже утверждена.
Конечно же, микросервисы. Конечно же, Kubernetes. Обязательно кафка для обмена сообщениями, потому что «нам нужна асинхронность». И база данных — непременно NoSQL, желательно шардированная, ведь мы готовимся к миллионам пользователей. Сразу. В первый день.
Проходит полгода.