---
title: "Amazon SQS"
description: "2 posts about Amazon SQS, summarised, each linking to the original."
---

# Amazon SQS
> 2 posts about Amazon SQS, summarised, each linking to the original.

## Articles

### [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.