See how a stream of updates handles problems.
Add bad or repeated records, send updates faster than the system can handle, or rebuild old data while updates continue. The counters show whether anything was lost or handled twice.
Bad records stop early
Records with impossible locations or invalid status changes are rejected before they can be saved.
Each update is saved once
Streams may resend the same record. An exactly-once check uses a record key to skip a repeat instead of handling it twice.
A waiting list protects records
When updates arrive too quickly, backpressure means they wait in a queue instead of being dropped. The queue count shows how far behind the simulation is.
Old data rebuilds safely
The simulation creates a corrected copy while new updates wait. It then switches to the copy in one step, which is called an atomic cutover.
This is an independent browser simulation, not a production data service. It uses generated updates shaped like public transport records so you can test each control without changing a real system.