Lingvo

01 Задача

Живой разговор между языками и аналитика встреч живут на одном backend, но у них разные требования к задержке: одному нужен realtime STT → MT → TTS прямо на аудио-пути, другому — структурированные саммари, action items и решения, извлекаемые после звонка. Оба должны работать на общем Django-ядре с единым биллингом и идентичностью.

02 Что сделал

Единый backend на Django + DRF + Celery обслуживает два Next.js-фронтенда (Translator и Meetings). WebRTC-медиа идёт через LiveKit SFU; отдельный Pipecat-агент на GPU-сервере подключается к комнате по WSS и крутит realtime-пайплайн, диспетчеризация — через Redis pub/sub, расход отдаётся обратно в backend. В Meetings добавлен note-taker-пайплайн плюс Celery-задачи на саммари и извлечение action items / решений, а Beat-задача собирает пред-встречный бриф через RAG по недавним встречам (эмбеддинги pgvector). Платежи — за адаптерами Cryptomus и YooKassa с идемпотентной монотонной обработкой вебхуков.

• ▸Один Django-backend обслуживает два Next.js-продукта (переводчик + встречи) с общим биллингом и идентичностью
• ▸Realtime STT → MT → TTS через Pipecat-агент на GPU поверх LiveKit SFU, диспетчеризация через Redis pub/sub
• ▸Саммари встреч, action items и решения извлекаются Celery; пред-встречный бриф через RAG по pgvector
• ▸Идемпотентные монотонные платёжные вебхуки за адаптерами Cryptomus / YooKassa

03 Результат

Один backend аккуратно несёт два продукта с разными realtime-ограничениями; аудио-путь остаётся на LiveKit, а control-plane идёт по Tailscale-mesh, знание о встречах ищется через векторные эмбеддинги. Решения зафиксированы как ADR.