Ситуация
Рост пользователей начал ломать обработку файлов
Проект активно рос: ежедневно приходили новые пользователи, и многие загружали файлы уже в первый день. При этом весь сценарий проходил через бэкенд.
- загрузка файла;
- сжатие, оптимизация, антивирус;
- отправка в облако;
- локальное хранение до завершения обработки.
Проблема
Бэкенд стал и транспортом, и процессором, и складом
- Обработка нагружала процессор и память, из-за чего росла очередь.
- Файл проходил через бэкенд дважды, что добавляло сетевые задержки.
- Реплики приходилось держать тяжёлыми из-за локального хранения файлов.
- Зависимость от медиа- и антивирусных библиотек усложняла деплой.
Из-за этого горизонтальное масштабирование не давало ожидаемого эффекта: система копировала саму проблему на новые реплики.
Решение
Я предложил вынести тяжёлые операции из слоя приложения
- загрузка файлов напрямую в S3 через pre-signed URL;
- асинхронная обработка через AWS Lambda;
- перенос логики обработки из бэкенда в облачные сервисы;
- хранение пользовательских файлов только в объектном хранилище;
- удаление тяжёлых зависимостей из приложения.
Внедрение шло без остановки системы и без изменений для пользователя. Требования по антивирусной проверке и контролю безопасности сохранились.
Результат
Бэкенд стал тонким и легче масштабировался
- вес одной реплики снизился примерно с 80–100 ГБ до 5 ГБ;
- одна реплика начала обрабатывать примерно на 40 % больше запросов;
- исчезло бутылочное горлышко при загрузке файлов;
- скорость стала стабильнее и меньше зависела от нагрузки;
- упростились деплой и запуск новых реплик;
- снизились инфраструктурные затраты.
Ключевая мысль
Проблема была не в объёме данных, а в неправильной ответственности слоя
Когда приложение и хранит файлы, и обрабатывает их, и отвечает за бизнес-логику, оно плохо масштабируется. Разделение ответственности и перенос тяжёлых операций в облако решают проблему системно.