Episode 13: Messaging & Event Architecture - SQS, SNS & EventBridge Explained | SAA-C03
Shownotes
Master decoupling! SQS, SNS, and EventBridge with the fan-out pattern and exam traps.
🔑 WHY DECOUPLING MATTERS
When apps talk directly and traffic spikes (10 videos suddenly becomes 1,000), tightly-coupled systems crash. Put a messaging layer between them and each part scales independently. SQS = queue. SNS = pub/sub. Kinesis = streaming.
📬 AMAZON SQS (QUEUE)
Producers send messages, consumers poll and process them.
STANDARD QUEUE:
• Unlimited throughput and messages
• Retention: 4 days default, 14 days max
• Message size: up to 256 KB
• At-least-once delivery (possible duplicates!)
• Best-effort ordering (possible out-of-order!)
VISIBILITY TIMEOUT: After a consumer polls a message it becomes invisible (default 30 sec). If not deleted in time, it reappears. Too short = duplicates. Too long = slow retries after a crash. Use ChangeMessageVisibility for more time.
LONG POLLING: Consumer waits up to 20 sec for messages. Reduces API calls and latency. Preferred over short polling.
FIFO QUEUE: First-In-First-Out ordering + exactly-once (deduplication). Throughput limited to 300 msg/s (3,000 with batching).
KEY PATTERNS:
• SQS as buffer before a database = no lost transactions during spikes
• SQS + Auto Scaling = scale consumers using ApproximateNumberOfMessages metric
📢 AMAZON SNS (PUB/SUB)
Send one message to many receivers. Producer publishes to one topic, all subscribers get a copy.
• Up to 12,500,000 subscriptions per topic; 100,000 topics per account
• Subscribers: SQS, Lambda, Kinesis Data Firehose, HTTP/S, email, SMS
• Integrates with CloudWatch Alarms, S3 events, ASG, RDS events
• SNS FIFO available (ordering + deduplication)
🔀 THE FAN-OUT PATTERN (HEAVILY TESTED!)
Push once to an SNS topic, receive in all subscribed SQS queues. Fully decoupled, no data loss, add subscribers anytime. CRITICAL: SQS queue access policy must allow SNS to write! Works cross-region.
Classic use case: S3 allows only ONE event notification per event-type + prefix combo. To send one S3 event to multiple queues, fan-out through SNS.
🎯 SNS MESSAGE FILTERING
JSON filter policies on subscriptions route messages (placed vs cancelled vs declined orders). No filter = subscriber gets everything.
⚡ AMAZON EVENTBRIDGE (formerly CloudWatch Events)
Two jobs: SCHEDULE cron jobs, and REACT to events with patterns.
• Sources: EC2 state changes, CodeBuild, S3, CloudTrail API calls, schedules
• Destinations: Lambda, SQS, SNS, Step Functions, ECS, Kinesis, and more
• Event buses: Default (AWS), Partner (SaaS), Custom (your apps)
• Resource-based policies aggregate events across AWS accounts
• Archive & Replay events; Schema Registry infers/versions structure
🧭 CHOOSING THE RIGHT SERVICE
SQS: queue, one message → one consumer, decouple/buffer
SNS: pub/sub, one message → many subscribers, notifications/fan-out
EventBridge: react to AWS events, schedule, SaaS integration, rich filtering
⚠️ TOP EXAM TRAPS
• Standard SQS = duplicates + out-of-order (need ordered? FIFO)
• Same message twice? Visibility timeout too short
• SQS retention max 14 days (longer? archive to S3)
• Fan-out failing? SQS access policy must allow SNS
• S3 = one notification per event-type+prefix (use fan-out)
• SNS alone doesn't persist (add SQS subscriber for retries)
• CloudWatch Events = EventBridge (same service)
• React to AWS events or schedule? EventBridge, not SNS
• Message over 256 KB? Store in S3, send reference
⏱️ TIMESTAMPS
00:00 Intro | 01:30 Why Decoupling | 04:00 SQS Basics | 08:00 SQS Advanced | 14:30 SNS | 19:00 Fan-Out | 23:00 SNS Filtering | 25:00 EventBridge | 31:00 Choosing | 34:00 Exam Traps | 39:00 Conclusion
Perfect for SAA-C03 prep and building decoupled, event-driven architectures!
#AWS #SQS #SNS #EventBridge #Serverless #SolutionsArchitect #SAAC03 #CloudComputing
⭐ 5-star rating if this helps!