A single case-closed event must feed both a searchable archive queue and a metrics queue, and each consumer must fail and scale on its own. Which pattern should the developer implement?
Select an answer to reveal the explanation.
Short Explanation
One megaphone, two mailboxes. SNS fans the same case-closed notice out to separate SQS queues so archive and metrics each scale and fail without taking the other down. One shared queue or a chained Lambda couples their fates; S3 list-polling is the wrong delivery bus.
Full Explanation
A single case-closed event that must feed both a searchable archive queue and a metrics queue—with each consumer failing and scaling on its own—should publish to Amazon SNS and subscribe a separate Amazon SQS queue for archive and another for metrics. SNS fans the event out; each SQS queue isolates backlog, IAM, concurrency, and poison handling. Archive outages must not block metrics, and vice versa.
Having one Lambda call both queues in sequence inside the same try/catch couples success: a metrics failure can undo or block archive progress depending on error handling, and scaling is shared. Writing once to S3 and having both queues poll with ListObjects reintroduces polling lag and listing cost. Putting both consumers behind one shared SQS queue with message attributes forces competing consumers to filter carefully and couples their scaling and failure modes on one backlog.
Exam caveat: SNS to SQS subscriptions need raw message delivery choices and DLQs per queue. FIFO versus standard depends on ordering needs; many analytics paths tolerate standard queues.
Operational check: publish case-closed to SNS; confirm two SQS subscriptions receive copies; test stopping archive workers while metrics continues; and alarm independently per queue.