Storage Queues

Overview

We use Storage Queues when the pattern is simple: a producer adds a work item, a worker takes it, and a failure can be retried a few times. The queue sits on a storage account you already operate, with a poison-message path so a bad item does not block the rest.

We document visibility timeout, dequeue count, and how the worker logs a failure. If the workload later needs topics or transactions, we say so and plan a move to Service Bus rather than stretching this queue.

What we deliver

• Storage queue with visibility timeout and message TTL set for the worker
• Worker pattern that deletes a message only after the work succeeds
• Poison-message handling after a stated dequeue count
• Identity-based access and a short note on when Service Bus would be the better fit

Business benefits

• Simple background work stops calling downstream APIs in the user request
• A failing item is set aside after a known number of attempts
• The queue uses storage you already run, without a separate messaging namespace