A meter-event consumer invokes Lambda once per SQS message, wasting per-invoke overhead. How should processing be optimized?
Select an answer to reveal the explanation.
Short Explanation
One Lambda wake-up per tiny meter tick pays the cold-start tax over and over. Bump the SQS batch size so one invoke chews through a handful of events. Less overhead, better cost and latency for the stream.
Full Explanation
A meter-event consumer that invokes Lambda once per SQS message wastes per-invoke overhead, so processing should increase the SQS-to-Lambda batch size so each invoke handles multiple meter events. Batching amortizes cold/warm invoke overhead and improves throughput for high-volume municipal meter ingestion, provided visibility timeout and partial batch failure settings still match processing time.
Setting batch size to one permanently maximizes per-message overhead and contradicts the optimization goal.
Replacing SQS with synchronous HTTPS posts from each meter removes buffering and surge absorption.
Disabling partial batch failure so poison messages block forever silently risks stalling the entire meter pipeline.
Exam caveat: Tune SQS event-source batch size with timeouts and partial-batch-failure for throughput versus poison handling.
Operational check: Raise batch size carefully, measure invoke count and processing duration, set visibility timeout above batch processing time, enable partial batch failure reporting, and watch meter lag metrics during a peak window. Keep the civic/municipal context in mind: AMI/meter bursts after storms need efficient batching or the city falls behind on usage events.