Chapter 17: AWS SQS

AWS SQS

If you’ve been following along, we already covered SNS (broadcast fan-out like a loudspeaker), EventBridge (smart event routing), and now SQS fits perfectly as the reliable waiting room or task buffer for your app. It’s the service you use when you need to make sure work gets done eventually, even if things get busy, slow, or fail temporarily.

Amazon Simple Queue Service (SQS) is AWS’s fully managed message queuing service — it lets you send, store, and receive messages between different parts of your application (or between apps) in a decoupled, asynchronous way.

In simple human terms: Imagine a busy Hyderabad restaurant kitchen during lunch rush.

• Waiter takes order → puts ticket in a queue board (SQS).
• Chefs pick tickets one by one when ready → cook → mark done (delete from queue).
• If one chef is slow/overloaded → tickets wait safely (no loss).
• During peak → add more chefs (scale consumers) → clear queue faster.
• If chef makes mistake → ticket can reappear (retry).

SQS handles the “queue board” part — reliably, durably, and at massive scale — so your frontend doesn’t crash if backend is slow.

1. Why Use SQS? (Core Benefits – Real 2026 Wins)

• Decoupling → Sender and receiver don’t need to be online at same time or know each other.
• Reliability → Messages stored durably across multiple AZs → no loss even during failures.
• Scalability → Handles any volume — from 1 message/sec to millions.
• Asynchronous processing → Frontend responds fast → heavy work (image resize, email send, report generation) happens later.
• Retry & buffering → Handles spikes (Diwali sales, IPL rush) without overload.
• Cost-effective → Pay-per-request — very cheap for most apps.
• Fully managed → No servers, no patching — AWS handles everything.

Real Hyderabad example: A food delivery app like Swiggy/Zomato clone

• User places order → frontend sends message to SQS (“New order #123”).
• Backend workers (Lambda/EC2) poll SQS → process payment, notify restaurant, assign rider.
• During lunch rush → queue fills → add more workers → auto-scale.
• If payment service slow → messages wait safely → no user wait, no crash.

Without SQS → direct call → slow payment = slow app = bad reviews.

2. The Two Queue Types (Very Important – Choose Wisely)

AWS SQS has two types of queues — this decision affects everything.

Beginner rule (2026): Start with Standard — 90% of cases. Use FIFO only when you must have order + no duplicates (e.g., bank transfer sequence).

3. Key Concepts & Features (Hands-On Essentials)

• Message — Up to 256 KB text/JSON/binary. Body + attributes (metadata).
• Visibility Timeout — When consumer receives message → hidden for X seconds (default 30s). If not deleted → reappears for retry.
• Dead-Letter Queue (DLQ) — Failed messages after max receives → go to DLQ for debugging.
• Delay Queues — Messages invisible for up to 15 min after send.
• Long Polling — Consumer waits up to 20s for message → fewer empty receives → cheaper.
• Batching — Send/Receive/Delete up to 10 messages at once → save costs & latency.
• Server-Side Encryption — SSE-SQS or KMS.
• Access Policy — IAM-like for who can send/receive.

4. Pricing in 2026 (ap-south-1 Mumbai – India Friendly)

• Free Tier (forever): 1 million requests/month (SendMessage, ReceiveMessage, DeleteMessage, etc.).
• Beyond free:
  • Standard: ~$0.40 per million requests (first 100B), then tiered discounts ($0.30 → $0.24 for ultra-high volume).
  • FIFO: ~$0.50 per million.
  • Data transfer: Free within region; cross-region/internet = standard AWS rates.
  • No charge for storage time (messages live 1 min to 14 days).

Real cost example: Small app: 100,000 orders/month → ~100k–200k requests (send + receive + delete) → usually ₹0 (within free tier). Medium app: 10 million requests/month → ~₹3,000–4,000/month (very affordable).

5. Real-Life Hyderabad Example: Image Processing Pipeline

Your startup’s photo-sharing app:

• User uploads photo → frontend sends message to SQS Standard queue “image-process-queue”: {“userId”: “abc”, “s3Key”: “photos/123.jpg”}.
• Multiple Lambda functions (or EC2 workers) poll queue → receive message → resize photo → generate thumbnail → store back to S3 → delete message.
• If Lambda fails (timeout) → visibility timeout expires → message reappears → another worker retries.
• During viral moment → queue grows → AWS auto-scales Lambda concurrency → clear fast.
• Cost: Mostly free tier + pennies.

Boom — decoupled, resilient, scalable.

6. Quick Hands-On (Free Tier – Do This Today!)

1. Console.aws.amazon.com → SQS → Create queue → “my-hyderabad-tasks” (Standard).
2. Send message: {“task”: “resize photo”, “file”: “pic.jpg”}.
3. Receive message (poll) → see it.
4. Delete it (or let visibility timeout expire → reappears).

Cost? ₹0.

Summary Table – SQS Cheat Sheet

SQS is the “don’t lose work, process when ready” service — pairs amazingly with Lambda for serverless, SNS for fan-out, or EventBridge for events.

Got it? Next?

• SQS + Lambda polling pattern?
• Dead-Letter Queue setup?
• Standard vs FIFO deep example?

Tell me — next class ready! 🚀📋