Sensor uploads arrive in unpredictable bursts that overwhelm downstream analytics if sent inline. How should architects protect throughput and avoid drops?
Select an answer to reveal the explanation.
Short Explanation
Put a shock absorber between the firehose and the analytics kitchen—SQS or Kinesis holds the burst so nothing spills on the floor.
Full Explanation
Sensor uploads arriving in unpredictable bursts will overwhelm downstream analytics if invoked inline. Buffering through Amazon SQS or Amazon Kinesis smooths bursts into analytics without dropping data and decouples ingest from processing speed. Invoking the analytics cluster synchronously for every upload with no buffer fails hard on overload. Dropping excess uploads during bursts and asking citizens or devices to resubmit manually loses telemetry. Writing bursts only to engineer laptops overnight is not an architecture. Exam caveat: choose SQS versus Kinesis based on ordering, replay, and fan-out needs; set DLQs/retention and autoscaling on consumers. Operational check: generate a burst of sensor uploads, confirm the buffer absorbs them, watch consumer lag drain, and verify zero drops relative to a synchronous baseline that times out. In municipal cloud governance, record the owners, success metrics, and rollback or restore contacts beside this technical choice so the next incident, budget review, or audit does not rediscover the decision from scratch under time pressure. In municipal cloud governance, record the owners, success metrics, and rollback or restore contacts beside this technical choice so the next incident, budget review, or audit does not rediscover the decision from scratch under time pressure.