Thema: idempotency
-
Stripe-API: Paginierung und Idempotency-Keys (starting_after, has_more und das 24-Stunden-Fenster)
Die List-Endpunkte der Stripe-API v1 paginieren über die sich gegenseitig ausschliessenden Cursor-Parameter starting_after und ending_before (limit 1–100, Standard 10) sowie das Flag has_more; Auto-Pagination-Helfer der Client-Bibliotheken durchlaufen alle Seiten. POST-Requests können einen Idempotency-Key tragen, dessen gespeichertes Ergebnis Stripe etwa 24 Stunden lang erneut ausliefert, danach können Keys gelöscht werden. Requests, die ein Rate Limit auslösen, erhalten 429 mit dem Header Stripe-Rate-Limited-Reason.
-
Idempotente Admin-Skripte schreiben: Prüfen vor Ändern, Drop-in-Dateien und Marker-Kommentare
Ein Admin-Skript, das ein Agent nach einem Teilfehler oder bei wiederholtem Zeitplan erneut ausführen könnte, soll das System im selben Zustand hinterlassen, ob es einmal oder fünfmal läuft. Drei Muster machen das zuverlässig: den Ist-Zustand vor der Änderung prüfen, separate Drop-in-Dateien schreiben, statt gemeinsam genutzte Dateien zu bearbeiten, und jeden vom Skript verwalteten Block markieren.
-
Idempotente Webhook-Verarbeitung: Delivery-IDs, Retry-Zeitpläne der Anbieter und schnelle Antworten
Alle grossen Webhook-Anbieter können dasselbe Event mehrfach zustellen und erwarten, dass der Empfänger mithilfe einer anbieterspezifischen Kennung dedupliziert: X-GitHub-Delivery, die Stripe-Event-ID, die event_id von Slack mit X-Slack-Retry-Num oder die webhook-id von Standard Webhooks. Die Retry-Zeitpläne unterscheiden sich stark: GitHub wiederholt nie automatisch (manuelle oder API-Neuzustellung behält die Delivery-ID), Stripe wiederholt im Live-Modus bis zu drei Tage, Slack dreimal innerhalb von etwa sechs Minuten.
-
Doppelte Zustellung unschädlich machen
Einen Deduplizierungsmarker und den beabsichtigten Datenbankeffekt gemeinsam committen, während externe Effekte als eigenständiges Konsistenzproblem behandelt werden.
Maschinenlesbar: JSON