Express Kurier. Direkt.
Auch Overnight.
x25pronto Schweiz bringt Ware direkt ans Ziel. Für kleine Ware fährt ein Auto. Für mehr Platz gibt es Transporter oder XL. Direkt, Express und Overnight fahren von Montag bis Sonntag. Freie Zeiten stehen im Kalender.
Webhook‑Architektur: Best Practices für zuverlässige Lieferstatus‑Events
Wie Sie eine robuste Webhook‑Architektur für Lieferstatus‑Events aufbauen. Fokus auf Retry‑Strategien, sichere Signaturen, Queueing und Monitoring für Schweizer Integrationen.
Kurzantwort
Eine zuverlässige Webhook‑Architektur liefert Lieferstatus‑Events robust, sicher und nachvollziehbar an Ihre Systeme. Wichtige Bausteine sind idempotente Events, gestaffelte Retry‑Logik, HMAC‑Signaturen, persistentes Queueing und umfassendes Monitoring. Zusammen reduzieren diese Massnahmen verlorene Events, Dubletten und falsche Zustände.
Warum Webhooks für Lieferstatus sinnvoll sind
Webhooks senden Ereignisse in Echtzeit an Ihr System, etwa Statusänderungen von Abholung bis Zustellung in Zürich, Basel oder Genf. Sie entlasten Polling‑APIs und liefern zeitnahe Updates. Dafür muss die Empfangsseite zuverlässig verarbeiten können.
Idempotente Events und eindeutige IDs
Jedes Event braucht eine stabile, eindeutige ID (z. B. UUIDv4) und einen Event‑Typ. Ihre API sollte Wiederholungen erkennen und seiteneffektiv behandeln. Idempotenz verhindert doppelte Buchungen oder falsche Statusübergänge bei mehrfacher Zustellung desselben Events.
Retry‑Strategien: Backoff, Begrenzung und Dead‑Letter
Nutzen Sie exponentielles Backoff mit zufälligem Jitter, z. B. 1s, 2s, 4s, 8s plus Jitter. Begrenzen Sie Versuche (z. B. 5–10) und verschieben Sie nicht zustellbare Nachrichten in eine Dead‑Letter‑Queue (DLQ). In der DLQ halten Sie Kontext für manuelle Nachprüfungen oder erneute Verarbeitung durch Support in Bern oder Lausanne.
Persistentes Queueing und best‑effort‑Zustellung
Setzen Sie eine persistente Message‑Queue (z. B. RabbitMQ, Kafka, managed Pub/Sub) zwischen Event‑Generator und Auslieferer. Die Queue puffert Lastspitzen, garantiert Reihenfolge (wo nötig) und bietet Sichtbarkeit auf Backlog. Alternativ ist ein write‑ahead‑log in Ihrer DB sinnvoll, falls kein separates Messaging gewünscht ist.
Sicherheit: HMAC‑Signaturen und TLS
Signieren Sie Payloads mit HMAC (SHA‑256) und einem gemeinsamen Secret. Übermitteln Sie die Signatur im Header, damit Empfänger in Basel oder Zürich die Echtheit prüfen. Pflicht ist TLS (HTTPS) mit aktuellen Cipher Suites. Rotieren Sie Secrets und bieten Sie Versionierung der Signatur‑Headers an.
Verarbeitung und Validierung beim Empfänger
Der Empfänger muss schnell antworten (2xx) und Events asynchron verarbeiten. Prüfen Sie Schema, Zeitstempel und Signatur. Validieren Sie Zustandstransitionen: Ein Paket kann nicht zuerst als "zugestellt" und dann als "abgeholt" gemeldet werden. Fehlerhafte Events zurückweisen mit klaren HTTP‑Codes und Logs.
Häufige Fragen
Wie lange sollte ein Sender auf eine Bestätigung warten?
Antwort: Geben Sie kurze HTTP‑Timeouts (z. B. 5–10s) für die Erstannahme, um blockierende Verbindungen zu vermeiden. Die eigentliche Verarbeitung sollte asynchron und über die Queue erfolgen.
Was tun bei Netzwerkfehlern auf Empfängerseite?
Antwort: Retry mit Backoff, dann DLQ. Informieren Sie Betreiber per Alerting. Bieten Sie eine Replay‑API an, um Events manuell neu auszulösen.
Wie verhindern wir Replay‑Angriffe?
Antwort: Signaturen mit HMAC plus Zeitstempel im Header. Akzeptieren Sie nur Events innerhalb einer kurzen Zeitspanne (z. B. 5–15 Minuten) oder halten Sie verarbeitete Event‑IDs, um Wiederholungen zu erkennen.
Welche Monitoring‑Metriken sind wichtig?
Antwort: Erfolgsrate (2xx), Fehlerklassen (4xx/5xx), Latenzverteilung, Queue‑Länge, DLQ‑Einträge und Replay‑Counts. Visualisieren Sie diese Metriken in einem Dashboard und richten Sie Alerts für Anomalien ein.