Een sorteermachinemonitor die elk pakket op de verkeerde baan vindt

Het magazijn installeerde een pakketsorteermachine die pakketten naar de banen van DHL, PostNL, bpost, Colis Privé, Evri en andere vervoerders stuurt. De sorteermachine kiest zelf de baan. Niemand aan de operationele kant kon zien hoe vaak dat goed ging.

Een pakket op de verkeerde baan vertrekt met de verkeerde vervoerder of blijft in een rolcontainer staan tot iemand het vindt. Zonder data kwamen missorteringen pas dagen later boven als klachten van vervoerders en tickets over zoekgeraakte pakketten. Een fout van de sorteermachine was niet te onderscheiden van een nieuw labelformaat.

De service moest ook veilig bereikbaar zijn. Het is het enige systeem dat de leverancier van de sorteermachine kan bereiken. Daarom had het eigen sleutels, een IP-allowlist en limieten nodig, en mocht het geen scans vertragen of kwijtraken als de sorteermachine opnieuw verstuurde.

Ik schreef de herkenning van vervoerders als een geordende lijst regex-regels, overgenomen uit de baanconfiguratie die met de leverancier van de sorteermachine is afgesproken. Specifieke prefixen gaan eerst en de brede bpost-regel van 24 cijfers als laatste. Een barcode die nergens op past, hoort op de error/manual-baan. De service leest de uitvoerbaan uit de scan of uit het apparaat-ID en markeert elke scan als correct, verkeerde baan of niet te controleren.

Elke scan krijgt een ID dat is gehasht uit de barcodes, de verzendtijd, het apparaat en de baan. Herhaalde scans hebben hetzelfde ID en tellen één keer mee over de huidige en vorige periode. Tellingen blijven in het geheugen en worden per periode als één document naar Firestore geschreven met atomaire ophogingen, elke 5 minuten of als een periode eindigt. Bij een mislukte schrijfactie blijven de tellingen bewaard voor de volgende poging, en bij afsluiten wordt eerst alles weggeschreven.

De beveiliging bestaat uit meerdere lagen. Er kunnen twee sleutels tegelijk actief zijn, zodat een nieuwe sleutel zonder downtime wordt uitgerold, en sleutels worden in constante tijd vergeleken. Berichten zijn beperkt tot een IP-allowlist, een token-bucket rate limit, vertraging bij verkeerde sleutels per adres en maximale groottes van 64 KB per scan en 2 MB per batch. Via een health-endpoint kan de host de service herstarten als die stopt.