Transit fare kiosks need processing close to stations for low latency rather than sending every transaction to a distant central region. Which approach best addresses that need?
Select an answer to reveal the explanation.
Short Explanation
Kiosks hate waiting on a faraway brain the way a ticket booth hates calling headquarters for every swipe. Edge computing puts smarts near the stations so latency drops. Shipping every tap to a distant region or deep archive first is the opposite of that design.
Full Explanation
Edge computing places processing near users and devices to reduce latency and WAN backhaul, rather than forcing every transaction to a distant central region. Transit fare kiosks that need low-latency authorization or metering at stations therefore benefit from edge nodes or ruggedized station appliances that decide locally and synchronize summaries upstream when connectivity allows. Archival deep storage in a single remote region optimizes long-term retention cost and is the opposite of real-time fare processing at the platform edge. Nightly batch FTP of kiosk logs provides historical reporting only and offers no local decisioning when a rider taps a card during a WAN blip. A single global write master database that every kiosk must reach synchronously concentrates latency, creates a brittle dependency, and undermines station operations during regional incidents. Exam caveat: on CompTIA Cloud+, edge is about proximity and latency for devices and citizens; it is related to—but not identical with—CDN caching of static web objects, and it is distinct from choosing a cold archive tier for rarely read data. Operational check: measure round-trip time from representative kiosks to the proposed edge versus the central region, confirm degraded-mode fare acceptance rules if the WAN drops, validate secure, ordered sync of fare events into the system of record, monitor edge device patching and certificates, and document which decisions may occur at the station without immediate central confirmation.