Сложный backend, AI-системы и интеграции — от архитектуры до production.

Проблема

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

Архитектура

Это не обёртка над одним LLM API, а платформа. Серверная часть на Go, интерфейс на Next.js и React, потоковый чат через WebSocket и SSE. Единый шлюз поверх нескольких LLM-провайдеров: умная маршрутизация по модели и цене, circuit breaker, резервные маршруты, подсчёт токенов и биллинг. Поверх шлюза — память и семантический кэш на pgvector, граф-редактор workflow с собственным движком исполнения и контуры проверки качества (eval). Отдельный контур — обучение LoRA для SDXL и FLUX и генерация через ComfyUI на арендуемых GPU.

Инженерные решения

1. Маршрутизация между провайдерами: выбор модели под задачу и стоимость, автоматическое отключение сбойного провайдера (circuit breaker), повторы и резервные маршруты — сбой одной модели не роняет продукт.
2. Память в три слоя: краткосрочный контекст в Redis, структурированные факты в PostgreSQL, семантический поиск в pgvector. Найденное взвешивается по уверенности, промпт собирается под бюджет токенов.
3. Семантический кэш ответов и eval-контур с LLM-судьёй: качество и стоимость измеряются, а не угадываются; A/B-эксперименты на реальных сценариях.
4. Биллинг без потерь: резервирование баланса в Redis, сверка платежей фоновым воркером. Защитные фильтры и проверка персонажа до и после генерации.
5. Движок workflow из узлов: граф-редактор в интерфейсе и исполнение шагов на сервере с наблюдаемостью каждого узла.
6. Отдельный GPU-контур: обучение LoRA, генерация через ComfyUI, сохранение внешности персонажа между генерациями; мощности арендуются в RunPod и Vast.ai.
7. Наблюдаемость и проверка под нагрузкой: метрики в Prometheus и Grafana, нагрузочное тестирование с k6, миграции без простоя, бэкапы, CI / CD.

Результат

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

Проблема

Клиент повторяет запрос по таймауту. Брокер доставляет сообщение повторно. Воркер падает после списания, но до коммита. Доставки «ровно один раз» в распределённой системе не существует — а списание, заказ или письмо должны случиться ровно один раз.

Архитектура

Шлюз на Node.js принимает событие только с Idempotency-Key и в одной транзакции пишет его вместе с записью в outbox. Ретранслятор на Java / Spring Boot доставляет outbox в Kafka (в стенде — Redpanda) с повторами и ограничением частоты. Потребитель на Java дедуплицирует через inbox-таблицу и выполняет бизнес-эффект в той же транзакции, что и отметку об обработке.

Инженерные решения

1. Доставка как минимум один раз (at-least-once) плюс идемпотентный приём дают бизнес-эффект ровно один раз. Гарантия держится на инвариантах в БД, а не на надежде.
2. Повтор с тем же ключом возвращает тот же ответ; параллельный дубль видит статус «в обработке», а не создаёт вторую запись.
3. Redis — быстрый кэш ответов и ограничение частоты. Если он недоступен, шлюз деградирует на PostgreSQL, а не падает.
4. Нагрузочные профили с 30% дублей и сценарии отказов воспроизводятся в docker compose; генератор нагрузки — на Python.

Результат

Открытый референсный проект: схема БД, сервисы, генератор нагрузки и описание экспериментов. Тот же подход — outbox, inbox, ключи идемпотентности — применим к платежам, заказам и интеграциям.

Проблема

Полноценные PDF-редакторы либо продаются по подписке, либо собраны на Electron: долгий старт, сотни мегабайт памяти, тормоза на больших документах. Цель — нативный редактор, который работает локально, быстро и без аккаунтов.

Архитектура

Слоистая система из статически линкуемых библиотек: core, render, editor, ui, платформенный слой и адаптер PDF-движка. PDFium спрятан за собственными интерфейсами Rivet, AppKit — за платформенными. Свой интерфейс с сохраняемым деревом элементов (retained mode) — без GUI-фреймворка и без браузера внутри.

Инженерные решения

1. Тайловый рендеринг с ограниченным кэшем — плавный скролл и зум без пересчёта всей страницы и без неконтролируемого роста памяти.
2. Сериализованный доступ к документу: PDF-движок не потокобезопасен, а интерфейс не должен ждать.
3. Стабильная идентичность страниц — основа undo / redo для перестановки, поворота, кадрирования, аннотаций и правки содержимого.
4. Правка настоящего содержимого PDF: перемещение объектов, редактирование существующего текста, замена изображений.
5. Фоновое сохранение с атомарной заменой файла: документ не повреждается при сбое. PDF JavaScript и XFA отключены, ключевые решения зафиксированы в ADR.
6. CI собирает и тестирует портируемые слои на macOS и Linux; тесты производительности ловят регрессии до релиза.

Результат

Сборка для macOS: просмотр, поиск, работа со страницами, аннотации, правка текста и изображений. Портируемые слои не зависят от платформы; нативные оболочки для Windows и Linux — следующий этап.