Бэкенд микросервисной платформы для сети автосалонов

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

Таких команд в компании около двадцати, и в каждой не больше трёх человек. Стек у всех общий, поэтому команды двигаются независимо. Любой разработчик может поднять динамическое окружение для своей ветки со своими Redis, компонентами и Jaeger. Кроме него есть статические окружения: dev, dev2, stage, pre-prod и prod.

Заказчик набирал разработчиков в команды, и к одной из них подключился бэкенд-разработчик Фортех. Работа длилась 1 год и 3 месяца и закончилась 30 июня 2026 года. Состав команды проекта: два фронтенд- и три бэкенд-разработчика, engineering-менеджер, QA-инженер, менеджер проекта, продуктовый лид и два аналитика.

Задача

Встроиться в новую архитектуру, пока она ещё складывалась, и закрыть бэкенд-задачи своего направления:

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

Ограничения задачи

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

Двадцать команд с одним стеком всё равно писали код каждая по-своему. Без общего стандарта каждая новая интеграция повторяла чужие решения с нуля.

Персональные данные клиентов (телефоны, почта, адреса) не должны попадать во внутренние сервисы, при этом сервисам по-прежнему нужно знать, кто делает запрос и что ему разрешено.

Решение

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

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

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

Авторизация без персональных данных. Фортех участвовал в разработке новой авторизации. Прослойка на Envoy разбирает токен и убирает из него персональные данные, а сервисы получают только синтетические атрибуты: идентификатор, роли и разрешённые операции.

Данные и инфраструктура. Разработчик доработал механизм миграций базы, сделал снапшоты по паттерну Outbox с выгрузкой в S3 и кэширование часто запрашиваемых ресурсов в BFF. Настроил CI/CD в GitLab для автоматических тестов и более быстрых релизов, поддерживал инфраструктуру на Docker и Kubernetes, начал покрывать ключевые сервисы unit- и e2e-тестами.

Архитектурные ревью. Наш разработчик участвовал в архитектурных ревью и консультировал по новому проекту. Пока лид направления был в отпуске, он неделю вёл команду: собирал ежедневные отчёты фронтенда и бэкенда, распределял задачи и участвовал в обсуждениях с сервисными аналитиками.

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

Сервис согласований стал прозрачнее: запросы видны в трассировке Jaeger, события идут через Kafka.

Новая авторизация, над которой работал Фортех, переводит внутренние сервисы на роли и разрешения вместо телефонов и адресов клиентов. Так требования закона о персональных данных решаются на уровне архитектуры.

За 1 год и 3 месяца разработчик Фортех стал частью команды заказчика: участвовал в архитектурных решениях и неделю вёл команду вместо лида, а не только закрывал задачи.

Частые вопросы

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

Зачем общий NPM-пакет, если стек у всех команд одинаковый?
Одинаковый стек не значит одинаковый код. Пакет даёт командам готовую авторизацию и общие механизмы, и новые сервисы не изобретают их заново.

Можно ли усилить команду, если компания в процессе перехода на новую архитектуру?
Да, но закладывайте время на доступы и на то, что процессы будут меняться по ходу работы. Здесь разработчик Фортех проработал в таком режиме 1 год и 3 месяца.