Opnieuw proberen volstaat niet: reconciliatie van asynchrone PHP-taken ontwerpen

Asynchrone taken maken het mogelijk om imports, synchronisaties, notificaties, documentgeneratie en integraties te ontkoppelen. Dat een berichtenconsument een bericht heeft verwerkt, bewijst echter niet noodzakelijk dat het bedrijfsresultaat correct is. Er kan succes zijn geregistreerd voordat een extern effect is bevestigd, er kan tussen twee stappen een storing zijn opgetreden, of dezelfde operatie kan meer dan eens zijn uitgevoerd.

Reconciliatie van asynchrone PHP-taken overbrugt dat verschil: het vergelijkt wat het systeem verwachtte te bereiken met het bewijs van wat er is gebeurd, detecteert ontbrekende zaken of afwijkingen en zet een gecontroleerde correctie in gang. Het vervangt noch de wachtrij, noch nieuwe pogingen, noch idempotentie; het vult die aan met een onafhankelijke verificatie.

Een technische uitvoering staat niet gelijk aan een bedrijfsresultaat

Een taak kan zonder uitzondering eindigen en toch een onvolledig proces achterlaten. Een applicatie maakt bijvoorbeeld een synchronisatieverzoek aan, de berichtenconsument roept een externe API aan en ontvangt door een netwerkonderbreking een niet-sluitend antwoord. Als deze zonder idempotentiesleutel opnieuw probeert, kan deze een duplicaat aanmaken. Als de berichtenconsument van succes uitgaat, kan het record ongesynchroniseerd blijven.

Ga evenmin uit van een bepaalde afleversemantiek van de messaging-infrastructuur. De mogelijkheid van herleveringen en dubbele uitvoeringen hangt af van de broker, diens persistentieconfiguratie, ontvangstbevestigingen, het gedrag van de berichtenconsument en de storingen die optreden. Het ontwerp moet deze eigenschappen verifiëren in de gekozen technologie en, wanneer duplicaten of herordening kunnen optreden, ze expliciet tolereren.

De operationele vraag is niet alleen ‘is het bericht geconsumeerd?’, maar ‘kan ik aantonen dat het verwachte effect bestaat, waar van toepassing precies één keer, en met de juiste gegevens?’. Voor dat bewijs is een bron nodig: een opvraagbaar antwoord van het externe systeem, een opgeslagen externe identificatiecode, een opgeslagen document of een bevestigde statuswijziging.

Opnieuw proberen, idempotentie en reconciliatie: verschillende verantwoordelijkheden

Opnieuw proberen behandelt tijdelijke fouten: tijdelijke onbeschikbaarheid, gebruikslimieten, korte blokkades of netwerkproblemen. Het is raadzaam een maximumaantal pogingen, progressieve vertraging, foutclassificatie en een bestemming voor berichten die aandacht nodig hebben te definiëren. Eindeloos opnieuw proberen kan een gegevensfout verbergen of een extern incident verergeren.

Idempotentie maakt het veilig om een operatie te herhalen. Dit kan worden bereikt met een stabiele operatie-id die naar een externe provider wordt gestuurd, een unieke beperking in de database, of een transactionele controle vóór het effect. Het betekent niet dat het effect heeft plaatsgevonden: het betekent dat een herhaling dit niet zou moeten vermenigvuldigen.

Reconciliatie zoekt naar openstaande, onvolledige of tegenstrijdige operaties en beslist wat er met elke operatie moet gebeuren. Dit is vooral nodig bij externe effecten, batchprocessen, updates van meerdere systemen of communicatie waarvan de ontvangst niet alleen vanuit de verzendende applicatie kan worden bewezen.

• Gebruik opnieuw proberen om fouten die als tijdelijk zijn geclassificeerd opnieuw te proberen.
• Gebruik idempotentie om te voorkomen dat nieuwe pogingen of herleveringen effecten dupliceren.
• Gebruik reconciliatie om de eindstatus te controleren en vastgestelde verschillen te herstellen.

De operatie modelleren en verifieerbaar bewijs bewaren

Een onderhoudbaar ontwerp scheidt drie concepten. De aangevraagde taak vertegenwoordigt de intentie, bijvoorbeeld ‘bestelling 452 synchroniseren’. Het verwachte effect definieert het waarneembare resultaat: ‘het externe systeem bevat de bestelling met versie 7’. De bevestiging slaat het bewijs op dat dit resultaat bestaat: externe identificatiecode, versie, tijdstempel, gevalideerd antwoord of het resultaat van een latere raadpleging.

Maak vóór het publiceren van een bericht een uitvoeringsrecord aan in een duurzame database. Als de applicatie eigen gegevens wijzigt en een bericht publiceert, overweeg dan het outbox-patroon: sla de bedrijfswijziging en de openstaande gebeurtenis op in dezelfde transactie, en laat de publicatie over aan een later proces. Zo vermindert het risico dat de lokale wijziging wordt bevestigd en het bericht verloren gaat, of dat een bericht wordt gepubliceerd voor een wijziging die is teruggedraaid.

Het record moet minimaal het volgende bevatten:

• Onveranderlijke en unieke operation_id, gebruikt om berichten, logs en externe aanroepen te correleren.
• Operatietype, betrokken entiteit en versie of vingerafdruk van de verwachte inhoud.
• Huidige status, aantal pogingen, volgende toegestane poging en tijdstempels.
• Idempotentiesleutel en, indien aanwezig, identificatiecode van de externe entiteit.
• Samengevat bewijs en veilige verwijzingen naar antwoorden of fouten, zonder geheimen of onnodige persoonsgegevens te loggen.
• Reden voor afsluiting, compensatie, verwerping of escalatie naar menselijke beoordeling.

Definieer expliciete transities, bijvoorbeeld: pending, processing, awaiting_confirmation, confirmed, retry_scheduled, manual_review, compensated en not_applicable. Elke transitie moet een verantwoordelijke en een controleerbare voorwaarde hebben. Een voorwaardelijke update, zoals alleen naar processing gaan als de vorige status pending is, vermindert gelijktijdigheidsconflicten tussen berichtenconsumenten.

Het reconciliatieproces opbouwen

Reconciliatie kan worden uitgevoerd met een geplande PHP-opdracht, een afzonderlijk werkproces of een operationele flow. Deze moet met tijdvensters werken: onderzoek geen operaties die seconden geleden zijn aangemaakt als de externe integratie normaal enkele minuten duurt. Definieer het venster met echte latentiegegevens en beoordeel het opnieuw wanneer limieten of providers veranderen.

Vergelijk voor elke in aanmerking komende operatie vooraf gedefinieerde bronnen van waarheid. De lokale database kan de autoriteit zijn voor de intentie en de versie van de gegevens; het externe systeem voor de vraag of het de entiteit heeft ontvangen of aangemaakt. Wanneer er geen betrouwbare manier is om het doelsysteem te raadplegen, kan het bewijs bestaan uit een ondertekende ontvangstbevestiging, een identificatiecode van de provider of een uitgestelde controle via een resultaatbestand.

1. Selecteer onbevestigde operaties die hun verwachte termijn overschrijden.
2. Controleer of het effect bestaat met operation_id, idempotentiesleutel of een eenduidige bedrijfssleutel.
3. Vergelijk relevante velden en versies, niet alleen het bestaan van de entiteit.
4. Classificeer het geval als afwezig, correct, afwijkend, ambigu of niet van toepassing.
5. Voer de toegestane actie uit en sla de beslissing met het bewijs op.

Een ambigu resultaat mag niet automatisch tot opnieuw in de wachtrij plaatsen leiden. Als een aanroep mogelijk een entiteit heeft aangemaakt maar er geen betrouwbare manier is om die op te vragen, kan opnieuw proberen een betaling, notificatie of document dupliceren. Blokkeer in die gevallen de automatische actie en stuur de zaak naar een overzicht van uitzonderingen met voldoende context om te beslissen.

Herstellen zonder nieuwe schade te veroorzaken

De actie hangt af van de afwijking en de kosten van een vergissing. Opnieuw in de wachtrij plaatsen is geschikt wanneer het effect ontbreekt en de operatie idempotent is. Compenseren kan een onjuist effect terugdraaien via een expliciete bedrijfsoperatie, niet via willekeurig technisch verwijderen. Markeren voor beoordeling heeft de voorkeur bij ambiguïteit, versieconflict of financiële gevolgen. Afsluiten als niet van toepassing is bruikbaar wanneer de entiteit volgens gedocumenteerde regels is geannuleerd of vervangen.

Ook handmatige reparaties moeten een spoor achterlaten: wie de beslissing nam, welk bewijs die persoon raadpleegde, welke actie die persoon toepaste en wat het resultaat was. Beperk rechten en vermijd knoppen die een operatie uitvoeren zonder de entiteit, versie, bestemming en het risico op duplicatie te tonen.

Observeerbaarheid en tests die het ontwerp valideren

Logs die zijn gecorreleerd op operation_id maken het eenvoudiger om een operatie te volgen tussen web, werkprocessen en externe diensten. Nuttige metrieken beperken zich niet tot uitzonderingen: meet de ouderdom van openstaande operaties, het aantal in handmatige beoordeling, de afwijkingsgraad, nieuwe pogingen per oorzaak en de tijd tot bevestiging. Waarschuwingen moeten afgaan op ophoping, ouderdom of het overschrijden van een termijn, niet op elke afzonderlijke fout.

Test representatieve storingen: uitval na het externe effect en vóór het opslaan van de bevestiging; dubbele uitvoering; bericht buiten volgorde; herstart van het werkproces; timeout met onzeker extern resultaat; langdurige onbeschikbaarheid; en versiewijzigingen terwijl een operatie open blijft staan. De test moet zowel de eindstatus als de afwezigheid van duplicaten en de kwaliteit van het opgeslagen bewijs controleren.

Voorbeeld: een record met een extern systeem synchroniseren

Stel dat een PHP-applicatie een klantrecord synchroniseert. Bij wijziging maakt deze de operatie sync_customer aan met een stabiele identificatiecode en de verwachte lokale versie. Het werkproces stuurt deze waarden als idempotentiesleutel naar het doel. Als het een geldige bevestiging ontvangt, slaat het de externe identificatiecode op en wijzigt de status naar confirmed.

Als de timeout optreedt na het verzenden van het verzoek, laat het werkproces de operatie in awaiting_confirmation. Het reconciliatieproces raadpleegt het doelsysteem met de idempotentiesleutel. Als het dezelfde versie vindt, bevestigt het de operatie. Als het die niet vindt, plant het een nieuwe verzending. Als het een andere versie vindt, markeert het de zaak voor beoordeling in plaats van gegevens te overschrijven die in het andere systeem mogelijk legitiem zijn gewijzigd.

Checklist om reconciliatie toe te voegen zonder het proces te herschrijven

• Inventariseer bestaande taken en geef prioriteit aan taken die externe effecten veroorzaken, geld, gereguleerde gegevens of moeilijk herhaalbare processen betreffen.
• Documenteer voor elk type het verwachte effect, de bron van waarheid en het bewijs waarmee dit kan worden bevestigd.
• Verifieer in de concrete broker en berichtenconsumenten wat er gebeurt bij uitval, late ontvangstbevestigingen, persistentie, herlevering en berichtvolgorde.
• Voeg een stabiele operation_id toe en propageer deze in het bericht, logs, externe aanroepen en statusrecords.
• Voer een operatietabel in met statussen, pogingen, termijnen, idempotentiesleutel en bewijs; begin indien nodig in observatiemodus.
• Definieer voorwaardelijke transities en een geschreven beleid voor opnieuw proberen, bevestigen, compenseren, escaleren of afsluiten als niet van toepassing.
• Implementeer een reconciliatieproces dat beperkt is tot een tijdvenster en één pilotoperatietype.
• Valideer met gevallen van duplicaten, ambigue timeouts, uitval tussen stappen, herordening en herstart voordat correcties worden geautomatiseerd.
• Maak een overzicht van uitzonderingen of een query met ouderdom, entiteit, bewijs en aanbevolen actie.
• Beoordeel periodiek metrieken, vastgelopen operaties en handmatige beslissingen om termijnen, regels en controles aan te passen.

Geleidelijke invoering maakt het mogelijk de betrouwbaarheid te verbeteren zonder de volledige architectuur te vervangen: maak eerst onzekere operaties zichtbaar, bevestig vervolgens resultaten en automatiseer ten slotte alleen de correcties waarvan u de veiligheid kunt aantonen.