# The upload froze the app for 8 seconds.

> The fix is the cheapest queue Azure sells, and a pointer instead of a payload.

- **Format:** short video, 10 steps, ~32 seconds
- **Topic:** Azure Queue Storage — moving image processing out of the upload request with a blob, a 182-byte message and a background worker.
- **Author:** Suthahar Jegatheesan (MSDEVBUILD)
- **Category:** Azure · Azure
- **Tags:** azure, azurequeuestorage, queuestorage, azurefunctions, blobstorage, servicebus, systemdesign, microsoftazure, azurecloud, cloudarchitecture, backenddeveloper, az305, msdevbuild
- **Canonical URL:** https://blog.msdevbuild.com/shorts/azure-queue-storage-image-upload/

---
## What you'll learn

- Why image processing inside the request exhausts the web tier
- The claim check: put a blob path on the queue, not the file
- How visibility timeout and DequeueCount handle a dead worker

## Understand it one step at a time

### 1. Upload. Then nothing happens

A 4.2 MB photo goes up and the screen just sits there. No progress anyone believes.

### 2. Your API is doing image work

Virus scan, three resizes, EXIF strip, then the blob write — all inside the HTTP request.

### 3. 20 uploads and the site is down

Each request pins a thread for 8.4 seconds. The web tier runs out long before the CPU does.

### 4. Fix: Blob + Queue Storage

Write the file to a blob, drop a tiny message on a queue, return 202. Ninety milliseconds.

### 5. Send the claim check, not the file

The message carries a blob path and 182 bytes of context. A 64 KB limit you will never hit.

### 6. A worker drains it in the background

A queue-triggered function picks the message up, does the eight seconds of work, and nobody waits.

### 7. Nothing is deleted until you delete it

Receiving only hides the message. If the worker dies, it reappears with DequeueCount up by one.

### 8. Poison? You handle that yourself

There is no automatic dead-letter here. The Functions trigger gives you a -poison queue after five tries.

### 9. Queue Storage vs Service Bus

One is already in the storage account you pay for. The other is a broker with features you may not need.

### 10. Return fast. Work later.

The user only ever needed to hear “got it”. Everything after that belongs to a worker.

---

## The takeaway

**The request should end when the answer is known**

Everything the user does not need to wait for belongs on a queue and a worker.