Streetlight sensors speak constrained field protocols, while the analytics platform expects Kafka producers. Which pattern best bridges that gap?
Select an answer to reveal the explanation.
Short Explanation
Tiny pole sensors are not laptop Kafka clients. A field gateway gathers frames, batches them, and speaks Kafka upstream—like a neighborhood post office for IoT. That is the usual bridge into the city bus.
Full Explanation
Streetlight and other constrained field sensors rarely speak Kafka natively, so field gateways that batch sensor frames and publish through Kafka producers are the standard bridge into city topics. Gateways aggregate, buffer, translate protocols, and present a manageable producer surface to the municipal bus. That pattern matches Syllabus Chapter 8’s conceptual path from field networks into Big Data messaging.
Requiring each sensor to open a direct Kafka connection with full desktop client libraries exceeds device resources, complicates credentials, and creates an unmanageable fleet of tiny producers. Replacing Kafka with email attachments from each pole controller destroys velocity, schema control, and operational observability. Running MapReduce on every streetlight locally confuses edge sensing with central ingestion and does not build the citywide analytics topic the platform expects.
Exam caveat: gateways become critical infrastructure—they need their own availability, buffering during backhaul loss, and secure producer credentials; a gateway outage can silence many poles at once. Operational check: disconnect a test gateway’s upstream path briefly, confirm local batching retains frames, and verify that after reconnect the Kafka topic receives the buffered telemetry without requiring each pole to speak Kafka directly.