A metro plans a mashup of 311 tickets and continuous IoT curb sensors. Which set of reference-architecture traits should drive the design rather than a favorite vendor slide?
Select an answer to reveal the explanation.
Short Explanation
311 plus curb sensors is mixed pace: tickets arrive in bursts, sensors never stop. Pick layers, scale-out, and a streaming lane—not the prettiest logo on a slide.
Full Explanation
A metro mashup of 311 tickets and continuous IoT curb sensors needs reference-architecture traits that fit mixed cadence: layered ingestion and processing, horizontal scale-out, and an explicit stream-capable path for sensor velocity—not a vendor logo chosen first. Batch-oriented 311 bursts and never-stopping curb telemetry cannot share one OLTP-centric design without losing either history depth or freshness for street operations. A single OLTP database with ad-hoc analyst accounts on production tables creates contention and cannot sustain continuous sensor velocity at analytics scale. Only batch PDF exports with no streaming path ignore sensor latency needs during live curb management and incident response. Desktop spreadsheets synced nightly to email lists are not a scalable municipal Big Data architecture and fail both auditability and concurrency. Exam caveat: BDPC expects layered reference thinking (ingest, process, store, serve) before product selection; streaming capability is a trait of the design, not a brand name on a slide. Operational check: sketch the city's ingest→process→store→serve layers, place 311 on a buffered batch or micro-batch lane and curb sensors on a streaming lane, and verify each layer has owners, SLAs, and horizontal-scale assumptions documented before procurement.