When a snow-emergency flag flips, the same alert must reach SMS subscribers, a dashboard queue, and a logging archive without the weather service calling each consumer itself. Which pattern should developers use?
Select an answer to reveal the explanation.
Short Explanation
One megaphone, many listeners — that is fanout. Publish the snow alert once and let SMS, the dashboard queue, and the archive each subscribe. The weather service should not dial every consumer itself.
Full Explanation
When a snow-emergency flag flips and the same alert must reach SMS subscribers, a dashboard queue, and a logging archive without the weather service calling each consumer, developers should use fanout—publish once (commonly to Amazon SNS) so each subscriber receives the alert independently. The producer announces “snow emergency active” once; SMS, dashboard, and archive each own delivery, retries, and scale. That keeps the weather service focused on meteorology and alerting semantics rather than maintaining a directory of every municipal consumer.
Having the weather service open direct HTTPS connections to every consumer and block until each replies creates brittle fan-out in application code: new consumers require redeploys, and one slow archive call delays SMS to plow crews. Storing the alert only on one EC2 instance’s local disk and hoping consumers SSH in is not a messaging architecture—it is an availability single point of failure. Replacing all consumers with one Lambda that must finish SMS, dashboard, and archive before returning couples unrelated failure modes and lengthens critical-path latency for citizen SMS.
Exam caveat: SNS fanout often pairs with SQS subscribers for durable processing; “SNS alone” versus “SNS to SQS” is an implementation detail. The tested concept is one publish, many independent consumers—not a synchronous mesh from the producer.
Operational check: publish snow alerts to a topic with a clear event schema; subscribe SMS, dashboard queue, and archive separately; verify adding a fourth subscriber needs no weather-service code change; and monitor per-subscription failures so one bad consumer does not hide others’ success.