Архитектурный анализ ArtHunt
Дата: Апрель 2026
Статус: MVP (v1.0, запуск 01.07.2026)
Стек: Go/Gin · PostgreSQL · MongoDB · Elasticsearch · RabbitMQ
Требования
Функциональные (MVP)
| Домен | Ключевые требования |
|---|---|
| Auth | Регистрация email+password, OAuth (VK/Google/Яндекс), JWT, подтверждение email |
| Специалисты | Профиль, портфолио (≥3 работ), теги, ценовой диапазон |
| Клиенты | Создание проектов, поиск специалистов, прямые приглашения |
| Матчинг | Отклики (1 на проект/специалист), приглашения (1 на клиент/специалист/проект) |
| Поиск | Полнотекстовый + тег-фильтры (стиль, жанр, техника, настроение, цвет, формат) |
| Модерация | Очередь проверки портфолио и проектов, блокировка пользователей |
| Поддержка | Тикет-система, уведомления по email |
Нефункциональные
| Требование | Целевое значение | Приоритет |
|---|---|---|
| Поиск | < 2 сек при 100 конкурентных запросах | Высокий |
| Доступность | 99.9% uptime | Высокий |
| Безопасность | Хешированные пароли, авторизация всех эндпоинтов | Высокий |
| Соответствие | ФЗ-152 (персональные данные) | Высокий |
| Масштабируемость | Горизонтальное масштабирование | Высокий |
| Наблюдаемость | Логирование событий, алерты на отказы | Средний |
Оценка нагрузки (3 мес после запуска)
MAU: ~650 пользователей (500 специалистов + 150 клиентов)
Проекты: ~45 в месяц (30% клиентов × 150)
Отклики: ~300 в месяц (~6-7 на проект)
Поисковые запросы: ~2 000 в месяц (консервативно)
Медиафайлы: ~6 000 файлов в портфолио (500 спец. × 12 работ)
RPS (пик): ~5-10 req/s — это низкая нагрузка для MVP
Вывод
Для MVP нагрузка незначительна. Архитектурные решения нужно оценивать с позиции операционной сложности, а не масштабируемости.
Текущая архитектура
┌─────────────────────────────────────────┐
│ Клиент (Browser) │
└──────────────────┬──────────────────────┘
│ HTTPS
┌──────────────────▼──────────────────────┐
│ Nginx (API Gateway) │
│ TLS termination · Rate limit · Proxy │
└──────────────────┬──────────────────────┘
│
┌──────────────────▼──────────────────────┐
│ Go / Gin (Monolith API) │
│ auth · specialists · projects · search │
│ responses · invitations · moderation │
└──────┬───────┬────────┬──────┬──────────┘
│ │ │ │
┌───────────▼─┐ ┌──▼───┐ ┌▼─────┴──┐ ┌──────────────┐
│ PostgreSQL │ │Mongo │ │ Open │ │ RabbitMQ │
│ основные │ │ DB │ │ Search │ │ async tasks │
│ сущности │ │ │ │ индекс │ │ email/notifs │
└─────────────┘ └──────┘ └──────────┘ └──────────────┘
Будущая архитектура
┌─────────────────────────────────────────────────┐
│ Клиент (Browser) │
└──────────────────────┬──────────────────────────┘
│ HTTPS
┌─────────── ───────────▼──────────────────────────┐
│ CDN (Yandex/VK Cloud / Cloudflare) │
│ статика, медиафайлы │
└────────────┬─────────────────┬───────────────────┘
│ API requests │ media
┌────────────▼────────────┐ ┌▼─────────────────┐
│ Nginx (API Gateway) │ │ Object Storage │
│ TLS · RateLimit · Proxy │ │ S3 / MinIO │
└────────────┬────────────┘ └──────────────────┘
│
┌────────────▼──────────── ────────────────────────┐
│ Go / Gin (Monolith API) │
└───┬──────────┬──────────┬──────────┬────────────┘
│ │ │ │
┌──────────▼──┐ ┌───▼──┐ ┌───▼──────┐ ┌▼─────────────┐
│ PostgreSQL │ │Redis │ │Elasticsrc│ │ RabbitMQ │
│ Основная БД │ │Cache │ │ Search │ │ Очереди │
└─────────────┘ └──────┘ └──────────┘ └──────┬───────┘
│
┌──────────▼───────┐
│ Worker (Go) │
│ email, ES sync │
└──────────────────┘
Анализ компонентов
Go + Gin
Плюсы: высокая конкурентность (goroutines), быстрая компиляция, production-ready фреймворк.
Риски: небольшая команда требует аккуратности с error handling, нет встроенного ORM.
PostgreSQL vs MongoDB
Проблема
MongoDB в текущей архитектуре практически не нужен для MVP. Все данные имеют чёткую реляционную структуру. Использование MongoDB создаёт операционную сложность без пользы.
Elastic/Opensearch
Правильное решение — теговая фильтрация является ключевым конкурентным преимуществом. Обеспечивает полнотекстовый поиск, фасетную фильтрацию, нечёткий поиск.
Риск: нужна стратегия синхронизации данных (паттерн Outbox + RabbitMQ).
RabbitMQ
Используется для email-уведомлений, обновления ES-индекса, логирования аналитики. Нужна Dead Letter Queue стратегия.
Компромиссный анализ
| Решение | Плюсы | Минусы | Рекомендация |
|---|---|---|---|
| Монолит (Go) | Просто, быстро, 1 репозиторий | Сложнее масштабировать части | Правильно для MVP |
| PostgreSQL | ACID, JOIN-ы, надёжность | Вертикальное масштабирование | Достаточно для MVP |
| MongoDB | Гибкость схемы | Лишняя сложность, нет ACID | Убрать из MVP |
| Elasticsearch | Мощный поиск | Eventual consistency, сложность | Необходим |
| RabbitMQ | Надёжные очереди | Ещё один сервис | Оправдан |
| Redis | Кеш, JWT revoke | Ещё один сервис | Добавить |
| Object Storage | Медиафайлы | — | Критично добавить |
Приоритизированные доработки
Критично (до запуска MVP)
- Object Storage — MinIO или Yandex Object Storage. Без него нельзя хранить медиа портфолио.
- Redis — JWT blacklist (logout), кеш тегов и профилей.
- ES-синхронизация — Outbox + RabbitMQ consumer.
Важно (первые 2 недели после запуска)
- Версионирование API — добавить
/api/v1/префикс. - Observability — Prometheus + Grafana + алерты.
- Dead Letter Queue в RabbitMQ.
Для v2.0
- CDN — раздача медиа при росте трафика.
- Rate limiting — защита auth-эндпоинтов от брутфорса.