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 MATTERSWhen 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 FILTERINGJSON 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 SERVICESQS: queue, one message → one consumer, decouple/bufferSNS: pub/sub, one message → many subscribers, notifications/fan-outEventBridge: 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⏱️ TIMESTAMPS00: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 ConclusionPerfect for SAA-C03 prep and building decoupled, event-driven architectures!#AWS #SQS #SNS #EventBridge #Serverless #SolutionsArchitect #SAAC03 #CloudComputing⭐ 5-star rating if this helps!