Een retry is geen tweede aankoopbeslissing
Koopstromen mislukken in de ruimte tussen een externe betaling en een in-game subsidie. Een ontvangstbewijs kan tweemaal arriveren. Een netwerkaanvraag kan time-out na de server vastgelegde staat, maar voordat de client het antwoord ontvangen. Een proces kan crashen na het reserveren van een transactie, maar voordat het toekennen van valuta. Bij herstart, de veiligste actie kan zijn om werk dat werd onderbroken opnieuw te proberen. Als het systeem behandelt elke retry als toestemming om te verlenen, dubbele rechten zijn een normaal gevolg van herstel.
Het nuttige onderscheid is intentie versus subsidie. Intent is het verzoek om een specifiek product te verkrijgen onder een specifieke transactie-identiteit. Grant is de duurzame game-side uitkomst: het recht eigendom, een valuta delta, een inventaris item, of een abonnementsperiode. Dezelfde intentie kan worden geleverd, gevraagd, opnieuw opgehaald, of opnieuw geleverd vele malen. Het moet nog steeds besluiten om één subsidiebesluit.
Dit is een engineering patroon, niet een platform-specifieke garantie. Verschillende winkels, betalingsproviders, en game backends bloot verschillende ontvangst, erkenning en terugbetaling gedrag. Neem niet aan dat een ontvangstbewijs bewijst een subsidie, of dat een bevestiging bewijst dat de speler zag een item. Bouw de server-side record zodat het spel kan aangeven wat het weet en veilig herstellen wanneer een extern resultaat onvolledig of vertraagd is.
Geef elke aankoop intentie een stabiele sleutel
Een idempotency sleutel bindt herhaalde levering pogingen aan een beslissing. Het kan voortvloeien uit een vertrouwde platform transactie identificatie wanneer die identificatie beschikbaar en geverifieerd is, of het kan worden uitgegeven door een server voordat een aankoop begint en later gekoppeld aan vertrouwde ontvangst informatie. De sleutel moet stabiel zijn over retries. Het creëren van een nieuwe willekeurige sleutel elke keer dat de client drukt op
Bewaar voldoende context met de sleutel om mismatches te weigeren: speler of account scope, productidentiteit, verwachte hoeveelheid of rechten vorm, bronkanaal, ontvangen tijd, verificatie status, en een toestand zoals in behandeling, commit, afgewezen, of needs-review. Houd gevoelige ontvangstmateriaal uit de gewone logs. Als ruwe provider payloads moeten korte retentie voor een geverifieerde recovery stroom, beschermen ze afzonderlijk en maken hun toegang opzettelijk.
Het datamodel heeft ook een uniekheidsgrens nodig. Voor een niet-verdienbaar recht kan uniciteit rekening plus product-ID zijn. Voor valuta is uniciteit meestal de grootboekingang of subsidietransactie in plaats van de huidige balans. Voor verbruiksartikelen kan een betrouwbare transactie-identificatie uniek zijn, zelfs wanneer het product-ID zich herhaalt. Definieer de sleutel alvorens het retrybeleid te coderen; anders kunnen twee subsystemen dedupliceren tegen incompatibele identiteiten.
Model van het onbekende commit resultaat
Het lastige resultaat is niet een schoon succes of een schone storing. Het is bekend dat de client niet weet of de server de subsidie heeft toegezegd. Een timeout, verbinding reset, proces herstart, of service uitval kan deze toestand produceren. De veilige client gedrag is om te vragen naar de transactie status of opnieuw proberen dezelfde intentie. De veilige server gedrag is om op te zoeken die intentie en terug te keren de duurzame beslissing in plaats van het toepassen van een andere mutatie.
Maak niet de clients weergave staat gezaghebbend. Een spinner verdwijnen, een lokale ontvangst cache, of een optimistische balans verandering kan de ervaring te verbeteren, maar het kan niet beslissen of de account eigenaar is van een recht. Server autoriteit betekent dat de server de geaccepteerde transactie op basis van het product ... vertrouwen grens, verbindt de duurzame record eenmaal, en geeft de huidige toestand wanneer opnieuw gevraagd.
De volgorde moet het gedeeltelijk aanvullen beleid zichtbaar maken. Bijvoorbeeld: ontvangen van intentie, valideren van vertrouwd aankoopbewijs, maken of laden van de duurzame grootboek record, commit het recht of valuta mutatie, markeer de toegestane record, bevestig externe levering indien van toepassing, dan het resultaat. Als het proces stopt tussen twee stappen, een recovery werknemer of later status query kan hervatten uit de duurzame record. De exacte bestelling is afhankelijk van de externe provider en game architectuur, maar de enige subsidie identiteit niet.
Bescherming van rechten en valuta-invarianten
Een idempotency key voorkomt herhaling van één intentie; het maakt niet automatisch elke bijwerking correct. Definieer de invarianten een subsidie moet behouden. Een niet-consumentable recht verschijnt ten hoogste eenmaal voor de rekening en het product. Een valutasubsidie heeft een grootboek toegang met één transactiesleutel, een bekende delta, en een resulterend saldo dat overeenkomt met de som van geldige vermeldingen. Inventaris subsidies gehoorzamen stack, capaciteit, en item-definitie regels. Een abonnementsperiode niet twee keer verlengen omdat de bevestiging eindpunt liep twee keer.
Maak de invariant controleren deel van dezelfde duurzame operatie die de subsidie committeert. Een lezing gevolgd door een later schrijven kan racen onder gelijktijdige levering. Twee werknemers kunnen beide observeren en beide subsidies. Gebruik transactieopslag, vergelijk-en-set semantiek, een geserialiseerde rekening mutatie pad, of een andere expliciete concurrency primitief geschikt voor de gegevensopslag. De belangrijke eigenschap is dat de beslissing en de marker niet onafhankelijk kunnen worden gewonnen door twee pogingen.
Voor games met een in-geheugen runtime, onderscheid duurzaam succes van presentatie. De server kan een speler zichtbaar evenwicht bijwerken na de duurzame grootboek invoer commits, maar de zichtbare update is niet het bewijs. Bij het opnieuw verbinden of herstarten, herbouwen van de gepresenteerde staat van de duurzame account record. Dat maakt een vertraagde client respons lastig in plaats van financieel onveilig.
Test crasht, herstart en opnieuw afleveren doelbewust
Begin met een deterministisch scenario. Creëer één account, één product, één bekende startbalans of set rechten, en één stabiele transactiesleutel. Voer de stroom uit, injecteer vervolgens een storing na elke genoemde grens: na ontvangst aanvaarding, na het aanmaken van het grootboek, na rechtenmutatie, na statusmarkering, na externe bevestiging, en nadat de respons is voorbereid. Start de relevante werknemer of proces opnieuw, probeer dezelfde sleutel, en bevestig de uiteindelijke duurzame toestand.
Het verwachte resultaat moet specifiek zijn. Een retry kan teruggeven met het oorspronkelijke resultaat, een lopende operatie hervatten, een niet-gematchte lading weigeren, of een record voor herziening bijhouden. Het mag geen tweede inventaris item toevoegen, een tweede valuta delta toepassen of de onbekende staat verbergen met een gefabriceerd succes. Leg de classificatie in het testresultaat vast zodat een latere refactor een opzettelijke hold niet kan omzetten in een toevallige duplicatie.
Gebruik relivery van ontvangst in hetzelfde scenario. Lever de exacte vertrouwde transactie twee keer af, lever hem dan af na een herstart en lever hem af naast een dubbele client retry. De resulterende grootboek- en rekeningstatus moet identiek zijn aan de single-delivery case. Als het product herhaaldelijke aankopen toestaat, voer dan dezelfde volgorde uit met twee echt verschillende transactie-identiteiten om te bewijzen dat het systeem niet over-dedupliceren per product ID alleen.
Hou de grenzen eerlijk.
Testen kan alleen de interacties die u uitvoert bewijzen. Een gesimuleerde provider response kan uw state machine valideren, maar het is geen bewijs dat elke productie provider rand precies hetzelfde gedrag. Een uitvoerbare test tegen een sandbox kan vertrouwen voor die integratie, maar heeft nog steeds verschillende operationele voorwaarden van een live store. Record of een scenario gebruik maakt van een simulatie, lokale adapter, sandbox, of geverifieerde provider omgeving.
De vertrouwensgrens moet ook duidelijk zijn. Een client mag geen willekeurige hoeveelheid, product-ID of "verifieerde" vlag indienen en een subsidie ontvangen. Inputs worden niet vertrouwd totdat de server ze valideert tegen de relevante configuratie en aankoop bewijs. Als de validatie niet kan eindigen, houd de intentie in afwachting of wijs het af met een herstelbare categorie. Laat een retry wachtrij geen bypass worden rond verificatie.
Privacy is van toepassing op deze testdiscipline. Fixtures moeten gebruik maken van synthetische transactiegegevens. Logs moet verwijzen naar een veilige test-identificatie, niet naar een ruwe ontvangstbon of accountnaam. Een productie-incident kan beperkt bewijs vereisen, maar de routine test suite mag nooit een tweede betaalgegevensopslag worden.
Praktische controlelijst
- Scheid een stabiele aankoop intentie van de latere game-side subsidie.
- Gebruik één idempotency sleutel over timeouts, retries, herstarten, en ontvangst herlevering.
- Bind de sleutel tot de rekening, product of rechten vorm, en vertrouwde bron context.
- Definieer duurzame staten zoals in behandeling zijnde, committed, afgewezen en behoeften-review.
- Dwingen tot uniciteit en valuta-ledger invarianten binnen dezelfde concurrency grens als de subsidie.
- Injecteer storingen na elke toestandsovergang, herstart en probeer opnieuw dezelfde bedoeling.
- Test dubbele levering en legitieme herhaalde aankopen afzonderlijk.
- Rapporteer onbekende uitkomsten eerlijk; zet geen timeout om in een uitgevonden succes.
- Houd ontvangst-achtige armaturen en test logs synthetisch en geredigeerd.
Veelgestelde vragen
Is een unieke bon ID genoeg voor idempotentie?
Het kan een nuttig onderdeel zijn wanneer de server kan controleren of de identiteit van de ontvangst betrouwbaar is en deze correct in te zien. Het is nog steeds belangrijk om het resulterende subsidiebesluit, mismatch beleid en recovery staat op te slaan. Een systeem kan dezelfde identificatie herhaaldelijk ontvangen, te laat ontvangen, of het ontvangen met een lading die niet overeenkomt met de opgeslagen productcontext. De duurzame record is wat maakt die gevallen inspecterenbaar.
Moet een klant automatisch opnieuw proberen na een timeout?
Meestal moet de statusresolutie opnieuw proberen met dezelfde intentie-identiteit, met begrensde back-off en duidelijke feedback van de gebruiker. Of het externe aankoopbewijs opnieuw moet worden ingediend hangt af van de provider en verificatie-ontwerp. Het onveilige gedrag is stil het creëren van een nieuw aankoopverzoek of het toepassen van een lokale subsidie omdat het oorspronkelijke antwoord verloren ging.
Hoe verschillen verbruiksartikelen van vaste rechten?
Permanente rechten meestal gededupliceerd per rekening en product. Verbruiksartikelen kunnen toestaan dat hetzelfde product worden gekocht vele malen, zodat de uniciteitsgrens moet een transactie identiteit of grootboek volgorde in plaats van product ID alleen. Beide nog steeds een duurzame subsidie voor elke geaccepteerde intentie.
Wat claimt Persistium hier?
Persistium is in ontwikkeling. Deze notitie legt algemeen toepasbaar integriteit en test-ontwerp patronen uit; het claimt geen publieke aankoop product, platform certificering, klant incident geschiedenis, of een gehoste service. De Continuïteit richting is geïnteresseerd in hetzelfde soort begrensd bewijs en replay-veilige recovery discipline.
