Production Readiness Checklist

Run this before any SQS-backed service reaches production. Each item links to the module that explains it. An item you cannot answer is not a checkbox you skip — it is a design decision nobody has made yet.

Configuration

• Visibility timeout set from the measured p99 processing time, not the mean — 08
• Long-running or variable work extends visibility via heartbeat rather than using a large constant — 08
• ReceiveMessageWaitTimeSeconds = 20 (long polling on) — 12
• MaxNumberOfMessages set explicitly (it defaults to 1) — 13
• Message retention set deliberately, not left at the 4-day default — 05
• Queue type (standard vs FIFO) chosen with a written justification — 06, 07
• For FIFO: MessageGroupId strategy documented, with the resulting parallelism ceiling stated — 07
• Message body is a versioned schema; consumers tolerate unknown fields — 04
• Payloads under 64 KB, or a claim-check to S3 — 18, 25

Reliability

• DLQ attached with a considered maxReceiveCount (typically 3–5) — 11
• DLQ retention longer than the source queue's (standard queues preserve the original enqueue timestamp) — 11
• Idempotency implemented, with the guard committing atomically with the effect — 09
• Idempotency-record TTL exceeds maxReceiveCount × visibilityTimeout and message retention — 09
• Duplicate delivery tested — an integration test delivers the same message twice and asserts one effect — 09, Lab 14
• Errors classified transient vs permanent; permanent failures are not retried maxReceiveCount times — 10
• Exponential backoff with jitter on transient failures — 10
• Circuit breaker for a sustained downstream outage — 10
• Behaviour during a long downstream outage computed: does anything expire before recovery? — 25
• No path deletes a message on failure (silent data loss) — 10

Scaling and performance

• Capacity math done: required concurrency, instance count, headroom — 15
• Binding constraint identified (consumers, downstream, or a quota) — 14
• Autoscaling on backlog-per-instance or oldest-message age, not raw depth — 14
• Scale-out fast, scale-in slow; cooldowns sized against processing time — 14
• Autoscaling maximum protects the downstream (connection pools, rate limits) — 14
• Backpressure: bounded internal work queue, blocking submit — 14
• Every relevant quota checked: in-flight, FIFO TPS, Lambda concurrency, DB connections — aws-facts.md
• Load tested against a realistic backlog, not an empty queue — 15

Deployment and lifecycle

• Graceful shutdown: SIGTERM stops polling, drains in-flight work, flushes deletes — 22
• Container grace period exceeds p99 processing time — 22
• Grace period and visibility timeout sized together — 08, 22
• Deploy tested for duplicate processing (deploy under load and count redeliveries) — Lab 15
• Per-message timeout inside the worker so one hung handler cannot hold a slot forever — 22
• Liveness probe reflects the poll loop, not just process existence — 22

Lambda consumers (if applicable)

• ReportBatchItemFailures enabled and the handler returns failed ids — 19
• Queue visibility timeout ≥ 6× function timeout — 19
• DLQ configured on the queue, not on the function — 19
• MaximumConcurrency set so the fleet cannot exhaust downstream connections — 19
• Poller ReceiveMessage cost included in the cost model — 18

Security

• IAM policies scoped to the queue ARN; no sqs:* on * — 16
• Separate producer and consumer roles — 16
• sqs:PurgeQueue restricted to an operator role — 16
• Encryption at rest enabled (SSE-SQS or SSE-KMS) — 16
• If SSE-KMS: producers and consumers have kms:GenerateDataKey and kms:Decrypt — 16
• Queue policy present for any cross-account or AWS-service access, with aws:SourceArn — 16
• aws:SecureTransport enforced — 16
• No PII in message bodies (retention + DLQ + logs all extend its life) — 16
• No credentials in source; IAM roles in every environment — 00

Monitoring and observability

• Alarm on ApproximateAgeOfOldestMessage, tied to the latency SLO — 17
• Alarm on DLQ depth > 0 — 11, 17
• Alarm on ApproximateNumberOfMessagesNotVisible approaching the in-flight quota — 17
• Alarm on redelivery rate (Received vs Deleted divergence) — 17
• Processing-duration metric emitted by the consumer (SQS does not provide it) — 17
• Correlation ID propagated via message attributes, present in every log line — 17
• ApproximateReceiveCount logged on every receive — 17
• Pipeline dashboard (producer → queue → consumer → downstream → DLQ) on one screen — 17
• NumberOfEmptyReceives monitored for cost — 18

Cost

• Monthly cost modelled from message rate, size and consumer count — 18
• Long polling and batching both enabled — 12, 13
• Queue tagged so the cost is attributable — 18
• KMS data-key reuse period tuned if SSE-KMS is enabled — 18
• Billing alarm set — 00

Operations

• Named owner for the queue — 25
• Runbook written, one section per alarm — 26
• DLQ replay procedure documented, including rate limiting — 11
• Runbook states explicitly: never purge, never redrive before diagnosing — 26
• Infrastructure as code — queue, DLQ, redrive policy, alarms and IAM as one unit — 25
• Multi-Region / DR position stated, with an RPO and RTO — 25

← Index: Course home