image-transformer

Задача

Написать высоконагруженный микросервис для обработки изображений. По HTTP приходит запрос, содержащий картинку в формате PNG, координаты прямоугольной области и тип преобразования. Нужно применить к картинке преобразование, вырезать нужный фрагмент и вернуть результат.

Стэк

• Фреймворк: .NET 10.
• ОС: Сервис будет запускаться в Linux-окружении (Ubuntu/Alpine).
• Ресурсы: Известно, что контейнер сервиса будет ограничен 8 GB оперативной памяти и 8 ядрами процессора.

API

Сервис должен принимать запросы на порту 8080 (например, http://localhost:8080/process/rotate-cw/0,0,20,20).

Единственный эндпоинт: POST /process/<transform>/<coords>

• Body: данные изображения в формате PNG (до 100 KB и 1000x1000 пикселей, формат 32bppArgb). При превышении указанных тербований возвращать 400 Bad Request.
• Преобразования: rotate-cw, rotate-ccw, flip-v, flip-h. При любом другом значении вовзращат 400 Bad Request.
• Координаты: x,y,w,h — координаты области относительно уже преобразованного изображения. В случае пустого пересечения области с картинкой возвращать 204 No Content.

Координаты отсчитываются от левого верхнего угла изображения (левый верхний пиксель имеет координаты 0, 0). Все 4 числа могут быть отрицательными, при этом каждое из них по модулю не превышает 2​^31​. Если прямоугольник выходит за границу изображения, он должен быть обрезан по границе изображения. Пример корректной строки ​ ​ для изображения размером 100x100: -5,-30,200,50 В этом случае в ответ должна попасть область изображения 0,0,100,20. Внимание! Обрезка изображения выполняется после поворота, т.е. координаты области заданы относительно уже повернутого изображения.

Требования к стабильности под экстремальной нагрузкой

1. Если нагрузка превышает возможности сервиса — производительность не должна деградировать. То есть, если сервис способен обработать максимум X rps, при нагрузке X * 2 rps сервис должен всё ещё обрабатывать не меньше X rps. Запросы, до которых очередь дойдет не скоро, можно сразу отклонять с ошибкой.
2. Производительность сервиса не должна деградировать со временем. Если сервис круглосуточно работает под нагрузкой без перезапусков, никакие ресурсы не должны закончиться и пропускная способность не должна уменьшиться.
3. Клиенты не должны замечать кратковременные задержки в работе сервиса. Если случилась пауза из-за GC, или ещё по какой-то причине сервис короткое время не обрабатывал запросы, клиенты не должны получить ошибок, если пауза действительно была небольшая.

Возможные сценарии нагрузочного тестирования

1. Линейный рост нагрузки от 1 rps до 10000 rps. Здесь определяется x — максимальное количество запросов в секунду, которое способен обработать сервис.
2. Постоянная нагрузка x - 10% rps. Измеряется latency (время выполнения) запросов.
3. Постоянная нагрузка x * 2 rps. Измеряется количество успешно обработанных запросов (должно быть ~= x) и latency (должно быть ~= latency при x - 10% rps).
4. Постоянная нагрузка x - 10% rps со всплесками в x * 10 одновременных запросов. Измеряется rps и latency после всплесков (должны вернуться к нормальным показателям для x - 10% rps).
5. Постоянная нагрузка x * 2 rps в течение часа. Измеряется стабильность rps и latency.