A payments notifier must publish events so billing and auditing can consume them independently without the notifier knowing every subscriber. Which pattern best fits?
Select an answer to reveal the explanation.
Short Explanation
Pub/sub is the city PA system—payments announce once, and billing plus auditing plug in their own radios. Point-to-point SSH or one hard-coded URL ties the announcer to every listener by name.
Full Explanation
A payments notifier should publish events to Amazon SNS or Amazon EventBridge (optionally with SQS subscribers) so billing and auditing can subscribe independently without the notifier knowing every consumer. That pub/sub fan-out is classic loose coupling: add or remove municipal subscribers without redeploying the notifier, and each consumer processes at its own pace.
Having the notifier call each billing and auditing database synchronously over SSH fails by concept because it creates tight, brittle, synchronous coupling and is not an event distribution pattern. Hard-coding HTTP posts to a single fixed billing URL and skipping auditing fails because it loses independent subscription and drops a required consumer. Storing payment events only in an EC2 instance’s memory until an operator copies them by hand fails as a durability and automation anti-pattern—memory is not a bus, and humans are not subscribers.
Exam caveat: Notifier must not know all consumers → SNS or EventBridge pub/sub (often with SQS for buffering). Synchronous point-to-point calls and manual memory handoffs contradict decoupled event distribution.
Operational check: Confirm topics/buses have separate subscriptions for billing and auditing, failures in one subscriber do not block the other, DLQs capture poison events, and publishing IAM permissions are least privilege. If the notifier still embeds every consumer URL, fan-out is not achieved.