SMM-API-Integrationen entwerfen, die Ausfälle überstehen

Die erste Version jeder API-Integration nimmt den glücklichen Pfad an: Du schickst eine Anfrage, du bekommst eine Antwort, die Bestellung ist aufgegeben. Der Produktivbetrieb lehrt dich etwas anderes. Netzwerke brechen ab, Endpunkte laufen in Timeouts, und der gefährlichste Fehler ist der zweideutige: die Anfrage, die vielleicht erfolgreich war oder auch nicht, bevor die Verbindung starb. Für diese Zweideutigkeit zu entwerfen, ist die ganze Aufgabe.

Idempotenz ist die Kernverteidigung. Hänge jeder Bestellanfrage einen eindeutigen Schlüssel an und lass den Server eine Wiederholung dieses Schlüssels als dieselbe Operation behandeln, nicht als eine neue. Jetzt ist ein Wiederholungsversuch nach einem Timeout sicher: Wenn die ursprüngliche durchging, bekommst du die bestehende Bestellung zurück statt einer doppelten Belastung. Ohne das ist jeder Wiederholungsversuch ein Glücksspiel mit deinem Guthaben.

Schichte Wiederholungsversuche mit Backoff obendrauf. Vorübergehende Fehler (ein 429-Rate-Limit, ein 503, ein Netzwerk-Reset) sollten mit zunehmenden Verzögerungen und einer Obergrenze wiederholt werden, nicht sofort bombardiert. Dauerhafte Fehler (ein 400 Bad Request, eine Antwort mit unzureichendem Guthaben) sollten schnell scheitern und einem Menschen vorgelegt werden, denn sie zu wiederholen verschwendet nur Zeit und verschleiert das eigentliche Problem.

Gleiche zuletzt ab. Protokolliere jede Anfrage und Antwort mit ihrem Idempotenz-Schlüssel und ihrer Bestell-ID und lass einen regelmäßigen Job laufen, der deine Aufzeichnungen mit den Bestellstatus des Panels vergleicht. Der Abgleich ist es, der die Bestellung erwischt, die auf dem Panel erfolgreich war, aber auf deiner Seite nicht aufgezeichnet wurde. SocialGOs API gibt konsistente Bestell-IDs und -Status genau deshalb zurück, damit diese Schleife unkompliziert aufzubauen ist: der Unterschied zwischen einer Automatisierung, der du vertraust, und einer, die du bemuttern musst.