Tirebase

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

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

Архитектура

Платформа состоит из 9 микросервисов, каждый отвечает за свою область:

API — центральный сервис. REST API для данных о товарах, остатках, ценах. Все остальные сервисы работают через него. FastAPI, PostgreSQL, SQLAlchemy 2.0.

Autoload Engine — генератор фидов для маркетплейсов. Формирует XML/JSON-выгрузки для Avito, Ozon, Wildberries, Яндекс.Маркет. Каждая площадка со своими требованиями к формату, категориям и атрибутам.

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

EVC (Event Communication) — сервис событийного взаимодействия. Обрабатывает события между сервисами через RabbitMQ. Уведомления, триггеры, реакции на изменения данных.

TS (Tire Service) — модуль шиномонтажа. Учёт записей, расчёт стоимости услуг, история обслуживания автомобилей.

BSCAN — сервис маркировки. Интеграция с CRPT для работы с «Честным знаком». Сканирование и валидация кодов маркировки.

PDF — генерация документов. Прайс-листы, накладные, акты выполненных работ. Шаблонизация через Jinja2, рендер в PDF.

Bot — Telegram-бот для менеджеров. Быстрый поиск по каталогу, проверка остатков, уведомления о заказах.

OCRM — операционная CRM. Управление заказами, клиентами, воронкой продаж. Vue 3 + TypeScript на фронте.

Технические решения

FastAPI выбран за нативную асинхронность и автоматическую генерацию OpenAPI-схемы — это критично, когда 9 сервисов общаются между собой. RabbitMQ вместо Redis Pub/Sub — потому что нужна гарантия доставки сообщений и очереди с подтверждением. Потерять событие о новом заказе недопустимо.

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

Деплой через Kamal на выделенные серверы. GitHub Actions собирает Docker-образы, прогоняет тесты и катит на прод. Вся инфраструктура описана в Docker Compose — новый разработчик поднимает локальное окружение одной командой.

Как CTO я отвечаю за всю техническую инфраструктуру: от архитектурных решений до CI/CD-пайплайнов и мониторинга.