A city outage notification system must deliver the same alert to SMS subscribers, email lists, and a Lambda function that writes an audit record. Which pattern fits?
Select an answer to reveal the explanation.
Short Explanation
One megaphone, many ears: SNS fans the same outage message to SMS, email, and Lambda without a brittle cron chain. A lone SQS consumer reinventing every channel misses the pub/sub point.
Full Explanation
A city outage notification system that must deliver the same alert to SMS subscribers, email lists, and a Lambda audit writer is a pub/sub fan-out problem. Publishing once to an Amazon SNS topic with SMS, email, and Lambda subscriptions delivers each message to heterogeneous endpoints without the publisher knowing each channel’s protocol details. That pattern keeps the notification producer simple and lets subscription lists evolve as departments add or remove channels.
Hard-coding three sequential API calls inside a single EC2 cron creates brittle latency coupling—if one channel is slow or fails, the whole job suffers—and duplicates retry logic poorly. Storing alerts only on an EBS volume for subscribers to poll is not push notification delivery. A single SQS queue with one consumer that must implement every delivery channel itself re-creates a monolith worker and loses SNS’s native multi-protocol fan-out.
Exam caveat: SNS fan-out vs SQS competing consumers—choose SNS when one message must reach many different subscriber types. Operational check: create the topic with three subscriptions, publish a test outage event, confirm SMS/email/Lambda each receive it, and add a DLQ or failure logging on the Lambda subscription for audit durability.