Episode 13: Messaging & Event Architecture - SQS, SNS & EventBridge Explained | SAA-C03

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!