Parking-sensor heartbeats arrive on Amazon Kinesis. Within seconds of arrival, records must be enriched and written to DynamoDB. Which pattern should the developer use?
Select an answer to reveal the explanation.
Short Explanation
Heartbeats are a firehose of tiny events—Lambda on the Kinesis stream is the near-real-time enrichment desk that can push into DynamoDB seconds later. Weekly batch jobs and Glacier-first paths are measured in much longer clocks.
Full Explanation
Parking-sensor heartbeats on Amazon Kinesis that must be enriched and written to DynamoDB within seconds should use a Lambda attached to the Kinesis stream event source to transform/enrich records and write in near real time. The event source mapping polls shards, batches records, and invokes your function continuously—matching the “within seconds” municipal operations need for occupancy dashboards and enforcement cues.
Buffering heartbeats in a nightly CSV to S3 with weekly batch processing misses the near-real-time requirement. Having each sensor call DynamoDB PutItem synchronously over the public internet with embedded access keys is an anti-pattern for credentials, fan-in, and device security. Writing every heartbeat only to Glacier Instant Retrieval and querying the archive for near-real-time dashboards fights the storage class’s purpose and latency expectations.
Exam caveat: configure batch size and parallelization carefully; handle poison records (bisect-on-error) so one bad heartbeat does not stall a shard. Use idempotent writes keyed by sensor and event time. Monitor IteratorAge to detect lag.
Operational check: attach Lambda to the stream; enrich and PutItem/BatchWrite with idempotent keys; alarm when IteratorAge exceeds a few seconds beyond SLO; and load-test shard counts for downtown sensor density.