Dispatchers need second-level visibility into ambulance-bay status, but the current feed is a nightly FTP of CSV dumps. Why is that pattern a poor fit?
Select an answer to reveal the explanation.
Short Explanation
A once-a-night USB drop cannot steer a live bay board. Messaging gives velocity; nightly FTP is batch luggage. For second-level ops, the bus beats the overnight folder.
Full Explanation
Nightly FTP CSV dumps lack the velocity messaging buses provide for second-level ambulance-bay status dashboards. Dispatchers who need near-real-time visibility require continuous event delivery, not a once-per-day file drop that is already hours stale when opened. Messaging ingestion is the pattern that matches public-safety operational tempo for bay status and similar facility feeds.
Claiming FTP CSVs are always more accurate GPS than any streaming topic confuses a transport schedule with data quality; accuracy depends on sensors and validation, not on choosing nightly files. Saying Kafka cannot carry status events for public-safety facilities is false at the conceptual level BDPC tests—status events are ordinary messages on a governed topic. Annual census extracts are even further from second-level operational dashboards and cannot meet dispatcher tempo.
Exam caveat: moving to a bus does not remove the need for schema, authorization, and operational data classification controls on public-safety adjacent feeds. Operational check: compare time-to-dashboard for a bay-status change over nightly FTP versus a test Kafka consumer and document whether only the streaming path meets the second-level visibility requirement for dispatch.