A smart-city architecture office must choose ingest patterns: streetlight controllers emit sub-second voltage samples, while the finance system exports ledger files once each night. How should the team match ingest frequency to those needs?
Select an answer to reveal the explanation.
Short Explanation
Don’t put a fire hose on a filing cabinet or a filing cabinet on a fire hose. Sub-second streetlight samples want streaming; nightly ledgers are happy as batch. One weekly Snowball, month-long device buffers, or forcing finance onto Kinesis just to “be modern” misses the latency match.
Full Explanation
High-performing municipal data architectures match ingest style to latency and cadence: streetlight controllers emitting sub-second voltage samples need streaming ingest, while finance ledger exports that arrive once each night are a natural batch ingest. Using streaming for telemetry and batch for nightly finance files avoids forcing both workloads through an ill-fitting single pipe. Forcing both workloads through a single weekly AWS Snowball job for uniformity introduces days of delay for streetlight monitoring and is operationally absurd for continuous IoT. Buffering streetlight samples for 30 days on device flash and only syncing when finance exports run destroys the operational value of sub-second telemetry and risks device storage failure. Rejecting all batch exports and requiring finance to rewrite every ledger line as a Kinesis record creates unnecessary engineering cost for a workload that does not need real-time streaming semantics. Exam caveat: “streaming versus batch” is a requirements question—do not pick Kinesis merely because it is popular if the SLA is nightly; conversely, do not pick nightly batch when alarms must fire in seconds. Operational check: document SLAs per source system, map each to streaming or batch tooling, and validate end-to-end latency with a streetlight spike test and a controlled finance file drop.