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!
