Transit dispatch needs many independent listeners when a bus route detour is published, without the publisher knowing each listener. Which messaging approach should application code use?
Select an answer to reveal the explanation.
Short Explanation
Detours should go out like a radio bulletin — one publish, many radios tuned in. SNS pub/sub lets listeners subscribe without the dispatcher hard-coding each one. That keeps the publisher blissfully unaware of the crowd.
Full Explanation
Transit dispatch that needs many independent listeners when a bus route detour is published—without the publisher knowing each listener—should use Amazon SNS pub/sub. Application code publishes the detour once; subscribers (rider apps, garage displays, accessibility alerts, analytics) each receive it without being enumerated in the publisher. That keeps the dispatch system stable when the city adds a new consumer for snow-route overlays or third-party trip planners.
Opening a dedicated TCP socket from the publisher to each known listener hostname creates a brittle mesh and operational nightmare across networks. Writing the detour only to one SQS queue owned by a single consumer provides competing consumers on one backlog, not independent fanout to heterogeneous systems with separate failure domains. Embedding every listener’s HTTPS URL in publisher source and redeploying when a listener is added is tight coupling disguised as integration.
Exam caveat: SNS push to HTTP/Lambda/SQS subscriptions still requires permission configuration and often SQS buffering for durable processing. Pub/sub does not by itself guarantee ordering across all subscribers.
Operational check: publish detours to a topic with route ID and effective window; add subscriptions without changing publisher code; verify one failing subscriber does not block others; and monitor delivery failures per subscription for rider-impacting channels.