---
title: "The SQS Decision Most Diagrams Skip: Normal Work vs. Broken Work"
description: "Amazon SQS connects producers and workers, but its real design test is failure. Compare the processing path with the signals and controls needed when queue operations break."
---

# The SQS Decision Most Diagrams Skip: Normal Work vs. Broken Work

**Type:** [Comparison](https://yomu.fyi/visual-explainers/category/comparison.md)

![Two-column comparison of a queue-backed worker system’s normal processing path and failure path, including polling, downstream work, injected queue errors, backlog, duplicates, and dead-letter effects.](https://yomufyi.s3.us-east-1.amazonaws.com/visual-explainers/4facd9af-de04-4d54-82fa-37d5eaf2cd81/image-067c2557-78d6-4441-9c57-ac3ddea9bc47.webp)

> Amazon SQS connects producers and workers, but its real design test is failure. Compare the processing path with the signals and controls needed when queue operations break.

## Explanation

Amazon SQS can sit between producers and workers so processing continues independently of connection ownership and worker lifecycles. This comparison puts the normal path beside the failure path: workers poll notifications and complete downstream work, while fault injection can block sending, receiving, deleting, visibility changes, or purging. Track backlog, message age, duplicates, failed sends, circuit-breaker state, and dead-letter-queue effects to decide whether the system is behaving safely under disruption.

**Tags:** [Amazon SQS](https://yomu.fyi/topic/amazon-sqs.md), [Architecture](https://yomu.fyi/topic/architecture.md), [AWS](https://yomu.fyi/topic/aws.md), [Distributed Systems](https://yomu.fyi/topic/distributed-systems.md), [Reliability](https://yomu.fyi/topic/reliability.md)

## Related reading

### [Red Hat edge platforms: Choosing the right one for your use case](https://yomu.fyi/post/red-hat-edge-platforms-choosing-the-right-one-for-your-use-case.md)
- Company: [Red Hat](https://yomu.fyi/company/red-hat.md)
- Author: Daniel Froehlich
- Published: Sep 11, 2026
- Type: Explainer

Choosing an edge platform requires balancing hardware footprint, workload needs, high availability, and operational complexity; the options range from RHEL with Podman or KVM to OpenShift clusters. The guide organizes Red Hat's offerings into RHEL-based and OpenShift-based deployments, noting that both traditional virtual machines and modern containerized workloads can coexist and that platforms can overlap as requirements grow. It details image-mode RHEL (bootc), transactional updates with rollbacks, efficient over-the-air delivery, offline installation, and dependency pre-resolution for constrained or disconnected sites. RHEL is positioned for static workloads of one to five components, while Red Hat Device Edge adds MicroShift when lightweight Kubernetes is needed. Kubernetes becomes more appropriate for larger microservices or event-driven systems, automated recovery, dynamic workloads, cross-environment scaling, and rolling updates; the series next covers OpenShift topologies.


### [Introducing automatic remediation policies with Cloudflare CASB](https://yomu.fyi/post/introducing-automatic-remediation-policies-with-cloudflare-casb.md)
- Company: [Cloudflare](https://yomu.fyi/company/cloudflare.md)
- Author: Michael Leslie
- Published: Sep 11, 2026
- Type: Announcement

Cloudflare CASB now supports automatic remediation policies that respond to newly detected SaaS security findings without requiring an administrator to act on each instance. Teams can match policies by vendor, integration or tenant, and finding type, then revoke file-sharing access, send finding details to webhooks, or do both; first-party remediation currently covers Microsoft and Google Workspace file and folder findings. The backend enqueues findings to Cloudflare Queues, uses a Worker to match policy configurations, and runs matched jobs through Cloudflare Workflows, which provides durable execution, retries, and rate-limit backoff. Policies generate administrator-activity and runtime execution logs, while the stated target from detection to completed remediation is five minutes or less; support for Custom Findings is planned for the coming weeks.


### [Building resilient real-time streaming workers with Amazon DynamoDB leases](https://yomu.fyi/post/building-resilient-real-time-streaming-workers-with-amazon-dynamodb-le.md)
- Company: [AWS](https://yomu.fyi/company/aws.md)
- Author: Siddhesh Tiwari
- Published: Sep 10, 2026
- Type: Tutorial

Managing hundreds of persistent outbound WebSocket connections requires explicit ownership because a failed worker can drop connections and stop data flow until they are reassigned. The described fleet-management pattern uses Amazon DynamoDB leases, conditional writes, and a global secondary index to ensure one worker owns each connection, renew ownership with heartbeats, and find expired leases for reconciliation. Amazon ECS on AWS Fargate workers poll Amazon SQS for notifications, maintain the WebSockets, and release or transfer ownership during graceful shutdown, failures, and scaling. The design also records desired state, the upstream URL, and the last processed sequence number in the lease item, while clock synchronization supports its time-based expiry. The post identifies heartbeat writes as the dominant DynamoDB cost and recommends provisioned capacity with Auto Scaling for sustained high connection counts, while noting that longer intervals reduce cost but extend failover.


### [Testing application resilience with Amazon SQS and AWS Fault Injection Service](https://yomu.fyi/post/testing-application-resilience-with-amazon-sqs-and-aws-fault-injection.md)
- Company: [AWS](https://yomu.fyi/company/aws.md)
- Author: Richard Whitworth
- Published: Sep 9, 2026
- Type: Tutorial

The post presents a resilience-testing tutorial for applications that depend on Amazon Simple Queue Service (Amazon SQS), where failed queue operations can stall downstream processing and trigger cascading outages. It uses AWS Fault Injection Service (AWS FIS) and AWS Systems Manager (SSM) Automation to apply a scoped deny resource policy that blocks data-plane actions, including sending, receiving, deleting, changing visibility, and purging, while preserving queue management. The experiment increases disruption across four phases, then observes producer-side and consumer-side behavior through application and Amazon CloudWatch metrics, including circuit-breaker state, failed sends, backlog, message age, duplicates, and dead-letter-queue effects. The guidance emphasizes hypotheses with measurable success criteria, non-production guardrails, tagged target queues, and a stop condition based on customer impact. It also describes consumer-only, partial, and compound-failure extensions, warning that concurrent experiments on one queue can leave a stale deny policy.