Spotifaychik — музыкальная платформа и production-инфраструктура

Музыкальный сервис как настоящая система

#

Spotifaychik — флагманский backend-проект в моём портфолио. Это не демонстрационный CRUD и не набор разрозненных лабораторных: внутри одного репозитория собрана основа музыкальной платформы, которую можно развивать до полноценного стримингового продукта.

Система управляет артистами, альбомами, треками, пользователями и плейлистами, поддерживает поиск и персональные сценарии, контролирует доступ к данным и работает в контейнерном production-контуре. От HTTP-запроса до метрик в Grafana весь путь спроектирован как единое приложение.

Исходный код на GitHub

Что получает пользователь

#

Платформа построена вокруг реальных музыкальных сценариев:

• изучать каталог артистов, альбомов и треков;
• находить музыку через глобальный и расширенный поиск;
• создавать, редактировать и публиковать собственные плейлисты;
• получать подборки популярных треков, артистов и новых релизов;
• формировать персональные плейлисты на основе истории прослушивания;
• управлять профилем, друзьями и пользовательской статистикой;
• загружать обложки и другие медиафайлы с проверкой и обработкой изображений.

За внешне простыми действиями находится полноценная доменная модель: связи между артистами, релизами и треками, принадлежность плейлистов, история прослушивания, роли, разрешения, сессии и журнал событий безопасности.

Масштаб проекта в цифрах

#

Архитектура, рассчитанная на развитие

#

Код разделён на четыре независимых уровня. Благодаря этому бизнес-сценарии не зависят от HTTP, база данных не проникает в доменную модель, а инфраструктуру можно менять без переписывания всего приложения.

MusicService.API
  ├─ Controllers, authentication, authorization
  ├─ files, diagnostics, Swagger
  └─ единая HTTP-граница
        ↓
MusicService.Application
  ├─ CQRS-команды и запросы
  ├─ handlers, validators, DTO и mapping
  └─ logging / validation pipeline
        ↓
MusicService.Domain
  └─ музыка, пользователи, права, сессии и аудит
        ↓
MusicService.Infrastructure
  ├─ EF Core, PostgreSQL и миграции
  ├─ хеширование паролей и security services
  └─ хранение файлов и фоновые процессы

Команды изменения данных и запросы на чтение разделены в CQRS-стиле. Логирование и валидация проходят через общие pipeline behaviors, поэтому контроллеры остаются компактными, а правила выполняются одинаково во всех сценариях.

Безопасность — часть архитектуры

#

Регистрация и вход построены на JWT-аутентификации. Доступ не ограничивается простой проверкой роли: в проекте реализованы permissions, изменение ролей, ресурсная авторизация владельца и отдельные authorization handlers.

• пароли хешируются через BCrypt;
• токены и пользовательские сессии учитываются отдельно;
• доступ проверяется на уровне ролей, разрешений и конкретного ресурса;
• чувствительные действия попадают в асинхронный журнал аудита;
• административный API позволяет анализировать события безопасности.

Такой подход показывает не только умение написать endpoint, но и понимание того, как защищать данные пользователей в большой системе.

Данные, поиск и работа с файлами

#

PostgreSQL хранит связанную модель музыкального каталога и пользователей, а EF Core отвечает за доступ к данным и развитие схемы через миграции. Для больших выборок предусмотрены пагинация, фильтрация и массовые операции.

Поиск вынесен в самостоятельный модуль и поддерживает несколько уровней — от обычного запроса до глобального и расширенного поиска. Файловый контур включает метаданные, сессии загрузки, контроль прогресса, валидацию и обработку изображений. Это превращает проект из «API с таблицами» в основу реального медиасервиса.

Production-контур

#

Приложение разворачивается не как один локальный процесс, а как связанная инфраструктура:

1. Nginx принимает внешний трафик, завершает TLS и балансирует запросы.
2. Несколько реплик ASP.NET Core API обрабатывают нагрузку без публикации внутренних портов наружу.
3. PostgreSQL работает с persistent volume и healthcheck.
4. Prometheus собирает метрики API и Nginx.
5. Grafana превращает телеметрию в рабочие дашборды.
6. Promtail и Loki собирают и индексируют контейнерные логи.
7. Отдельный сервис фиксирует события Docker — перезапуски, завершения и OOM.

Каждый backend-инстанс возвращает X-Instance-Id, поэтому round-robin можно проверить напрямую. Количество реплик меняется одной командой --scale app=N: конфигурацию Nginx, Compose и Prometheus переписывать не требуется.

Автоматическая поставка

#

GitHub Actions запускает полный маршрут изменений: восстановление зависимостей, сборку, тесты, создание Docker-образа, публикацию в registry, уведомление и развёртывание через self-hosted runner. Multi-stage Dockerfile отделяет SDK-окружение от компактного runtime-образа.

Это важная часть проекта: репозиторий демонстрирует не только код приложения, но и путь этого кода до работающего сервиса.

Надёжность и проверяемость

#

Тестовый набор охватывает доменные сущности, команды и запросы, контроллеры, валидацию, обработку ошибок базы данных и инфраструктурные сценарии. Для EF Core подготовлены отдельные фабрики контекста и тестовые seed-данные, а для файлового контура — временное хранилище.

Healthchecks контролируют состояние API, PostgreSQL и Nginx. Диагностические endpoints и скрипты позволяют проверить балансировку, доступность сервисов, метрики и статические файлы без ручной настройки окружения.

Запуск одной командой

#

git clone https://github.com/pistaha/spotifaychik.git
cd spotifaychik
cp .env.example .env
./start.sh

После запуска доступны API и Swagger через Nginx, метрики Prometheus и дашборды Grafana. Готовые скрипты помогают проверить состояние контейнеров и увидеть, как запросы распределяются между репликами.

Почему этот проект важен

#

Spotifaychik показывает проектирование системы целиком. Здесь нужно было одновременно думать о понятной доменной модели, удобстве развития кода, защите пользовательских данных, работе с медиа, производительности, тестировании и эксплуатации.

Главный результат — не количество endpoint’ов и контейнеров, а связность решения: пользовательский сценарий превращается в команду или запрос, проходит проверки безопасности и валидацию, сохраняется в PostgreSQL, наблюдается через метрики и логи и автоматически доставляется в production-контур.

Это проект, в котором backend-разработка соединяется с DevOps и системным мышлением — от первой сущности до масштабируемого запуска.