Hastighedsbegrænsninger før produktion af OTP

Produktion af OTP uden hastighedsbegrænsninger er som en åben vandhane for din forudbetalte saldo. Begrænsninger skal implementeres før Live-drift, ikke efter at økonomiafdelingen spørger, hvor pengene blev af. Denne side er din hastighedsport: hvem, hvor og hvor hurtigt — adskilt fra TTL/gensendelseslogik og verifikationsdebiteringer.

Hastighed er ikke det samme som TTL

TTL definerer kodens levetid. Hastighed definerer, hvor mange forsøg en identitet eller destination må generere. Nedkøling styrer gensendelser; hastighedsbegrænsning stopper selve bygen. Forveksles de, tømmes saldoen trods TTL-overholdelse. Brug begge dele og angiv hvilken port der udløste status.

Begrænsninger pr. identitet, destination og vindue

Port OTP før Live-sprog

Aktiver ikke produktion af OTP, mens hastighedsbegrænsninger kun er udkast. Grønt lys på én teststi beviser ikke hastighedskontrol. Krav: konfiguration, fail-closed test, eksport af udløst begrænsning, og kobling mellem begrænset intent og hold-status. Start ærligt: Når lancering er blokeret: status uden løgn.

Ærlig status for produkt og finans

Når en begrænsning udløses, skal status angive begrænset/afvist — aldrig leveret eller lydløst droppet. Produkt og finans deler dette sprog (Fælles statussprog for produkt og finans). Gentagelser med samme idempotens-nøgle må ikke omgå begrænsningen. Debet-klarhed forbliver separat: OTP-leveringsdebet versus verify-session.

Købers tjekliste for hastighedsbegrænsninger

1. Findes begrænsninger pr. identitet og destination før produktion?
2. Er fail-closed bevist — giver byger en ærlig begrænsning?
3. Navngiver eksporten den udløste begrænsning?
4. Er Live-sprog blokeret, mens begrænsninger er udkast?
5. Er wallet-stopgrænser aktive ved siden af hastighedsbegrænsninger?
6. Er overrides navngivne, tidsbegrænsede og lukket af en begrænset test?

Ethvert nej holder hastighedsportene i udkast.

Start med IOSOR

Åbn IOSOR-konsollen, og konfigurer hastighedsbegrænsningsregler på tværs af identitet, destinationskorridor og IP-interval, før du frigiver din OTP-pipeline til produktion. Udør en simuleret spidsbelastningstest for at kontrollere, at hastighedsgrænserne returnerer en umiddelbar begrænset eller afvist status via webhook. Sørg for, at din udrulningsvagt blokerer produktionsstatus, indtil hvert hensigtsvindue fejler lukket korrekt.

IOSOR-pointe

Denne artikel beviste, at levetid (TTL) alene ikke kan beskytte din OTP-pipeline mod dyre trafikpeaks. Effektiv rutebeskyttelse kræver særskilte hastighedsgrænser knyttet til konti, destinationskorridorer og IP-familier, som håndhæver faste stoplinjer, før trafikken når produktionen.