Архитектурные подходы

Выбери подход к построению сервиса транскрибации и протоколирования

A

Монолит на Python (FastAPI)

Стек: FastAPI + Celery + PostgreSQL + Redis + React

Единое приложение: API, обработка задач, боты, веб-интерфейс — всё в одном репозитории и процессе (+ воркеры Celery для тяжёлых задач).

✓ Плюсы

  • Простота разработки и деплоя
  • Один язык, одна кодовая база
  • Быстрый старт — MVP за недели
  • Легко отлаживать

✗ Минусы

  • Масштабирование — только вертикальное
  • Боты, API, обработка связаны — падение одного влияет на всё
  • При росте код станет сложным
B

Модульный монолит с очередями (рекомендация)

Стек: FastAPI + Celery + PostgreSQL + Redis + React/Vue

Единый деплой, но внутри — изолированные модули: API, транскрибация, генерация протоколов, боты мессенджеров. Общение между модулями — через очереди задач (Celery/Redis). Каждый модуль можно выделить в отдельный сервис позже.

✓ Плюсы

  • Баланс простоты и масштабируемости
  • Модули изолированы — падение воркера не роняет API
  • Легко выделить модуль в микросервис при росте
  • Один деплой, но чистая архитектура

✗ Минусы

  • Чуть больше начальной настройки чем чистый монолит
  • Нужна дисциплина разделения модулей
C

Микросервисы (Docker Compose)

Стек: FastAPI сервисы + RabbitMQ/Redis + PostgreSQL + React + Docker

Каждый компонент — отдельный контейнер: API Gateway, Transcription Service, Protocol Generator, Telegram Bot, Lensa Bot, Web Frontend.

✓ Плюсы

  • Максимальная гибкость и масштабируемость
  • Независимый деплой каждого сервиса
  • Полная изоляция компонентов

✗ Минусы

  • Сложность: сеть, мониторинг, логи, оркестрация
  • Оверкилл для одного сервера
  • Долгий старт разработки
  • Сложная отладка