A utility AMI platform emits one meter event that must trigger analytics, alerting, and archival compute paths without blocking the producer. Which messaging pattern best enables elastic fan-out?
Select an answer to reveal the explanation.
Short Explanation
One meter tick, many listeners—that’s pub/sub fan-out, not a single worker doing everything in line. SNS (or similar) fans the event so analytics, alerts, and archives each scale on their own. One sync loop, a global lock, or hourly FTP polling bottlenecks the utility stream.
Full Explanation
One meter event that must drive analytics, alerting, and archival compute without blocking the producer needs publish/subscribe fan-out. Amazon SNS (or an equivalent pub/sub design) publishes once and delivers to multiple subscribers so each path scales independently—analytics, alerts, and archives process in parallel at their own rates. That elastic fan-out pattern is the Task 3.2 messaging approach for high-scale utility AMI platforms. A single EC2 worker that processes analytics, alerts, and archives in one synchronous loop fails because the producer or pipeline waits on the slowest step and cannot scale each concern independently. A global relational lock table that allows only one consumer system-wide fails conceptually by serializing the entire utility stream and destroying parallelism. FTP drops to a shared folder polled hourly by each team fail because slow polling introduces latency, weak delivery semantics, and poor elastic scale compared with managed pub/sub. Exam caveat: fan-out still needs failure isolation—one bad subscriber should not poison others—and you must design retry, DLQ, and idempotency for meter events that may be redelivered. Operational check: publish a test meter event to SNS with three subscriptions, verify each path receives and scales under load independently, and monitor delivery failures per subscriber during a simulated AMI spike.