BACKEND / BACKGROUND JOBS
Upscale Service
Long-running image processing belongs outside the HTTP request.
Flask accepts an image, Celery processes it with an EDSR model and the client fetches the result using a task identifier.
- Backend
- Flask
- Queue
- Celery / Redis
- Processing
- OpenCV / EDSR ×2
01 / CONTEXT
The engineering problem
The interesting part is the long-running job: accept the upload, return a task ID, poll its status and download the output separately.
02 / FLOW
An image request
- 01
POST /upscale
Validate the file field and extension, then store input bytes in Redis with a TTL.
- 02
Celery queue
Return a task UUID; a separate worker reads and upscales the image.
- 03
GET /tasks/{id}
Report task state and the download path when complete.
- 04
GET /processed/{id}
Serve the PNG from Redis without writing a permanent file.
03 / SOURCE
Evidence in the source
- Three HTTP endpoints and a separate processing worker.
- One-hour TTL for input and output data in Redis.
- Tests for missing uploads and an end-to-end processing path using eager Celery.
- Docker Compose includes Flask, Redis and Celery.
04 / LIMITS
Outstanding work
- No explicit upload size limit or content signature validation.
- A max_retries setting does not automatically retry without a self.retry invocation.
- Redis outages, missing workers, broken inputs and expired files need more tests.
- Tests were inspected but not executed in this audit. No public live demo is claimed.
05 / VERIFICATION
Source evidence
See app.py, tasks.py, tests/test_api.py and docker-compose.yml. Celery runs eagerly in tests, so they do not validate the real distributed queue.
Why it belongs here
It demonstrates a different backend task: file handling, long-running work and time-limited results.