Nõuandev konstruktsiooni järgi

1. septembril 2026 lõpetas ühe Eesti veebipoe klient kassa. Selles päringus kutsus poe server Heatraili, ja vastus tuli umbes kolmandiku sekundiga. Klient ei näinud sellest midagi, mis on kogu mõte. Kui vastus oleks võtnud kaks korda kauem või poleks kunagi saabunud, oleks sama kinnitusleht laaditud samal hetkel ja pood oleks selle tellimuse kohta lihtsalt signaalita jäänud. See artikkel räägib, miks see on fakt süsteemi kuju, mitte lubadus selle kättesaadavuse kohta.

Omadus

Heatrail ei saa ostu peatada, viivitada ega tühistada, sest seda võimekust ei ole. Vastus on andmed. Kui ta ei saabu 800 ms jooksul, loobub poe enda klient kutsest (fail-open) ja tellimus läheb edasi.

Miks see kehtib

Eemaldatud võimekus, mitte lubadus

Heatraili kutsutakse üks kord tellimuse kohta, poe serverist, hetkel, mil tellimus on minemas makseteenusele. Ta vastab skoori ja põhjuste nimekirjaga. Mida ta selle vastusega teha saab, on mitte midagi: tagasikutset ei ole, veebihaaki, mis makset väravana hoiaks, ei ole, seadistuslülitit, mis nõuandva jõustavaks muudaks, ei ole, ega tugipäringut, mis ühe neist tooks, sest midagi sisse lülitada ei ole.

Põhjendus on lühike. Teenus, mis kassat peatada saab, teeb seda lõpuks halvimal võimalikul hetkel, vale põhjuse pärast. Iga sellist teenust juhivad inimesed, kes kavatsevad vastupidist, ja kavatsus ei ole see, mis katki läheb. Katki läheb reedene halb deploy, sõltuvus, mis vaikib, reegel, mis oli eelmisel kvartalil õige, või operaator, kellele keegi hoovaga survet avaldab. Lubadus elab neist üle ainult seni, kuni kõik teda mäletavad. Puuduv võimekus elab neist üle ilma, et keegi midagi mäletaks.

See on põhjus, miks piir on selles kogus öeldud esimesena, mitte viimasena. Kõik muu, mida Heatrail teeb, on väide täpsuse kohta, ja väide täpsuse kohta on väärt ainult millegi käest, kes ei saa valesti olemise peale tegutseda.

Eelarve on poe poolel juhtmest

800 ms eelarvet jõustab poe enda protsess, lisa ja teek, mitte miski, mida meie jooksutame. Eelarve möödudes loobub klient päringust, paneb payloadi kohalikku kordusjärjekorda ja annab juhtimise kassale tagasi, mis teeb siis seda, mida ta niikuinii oleks teinud.

Tagajärg väärib selgesõnalist ütlemist, sest ta pöörab tavalise tarnijasuhte ümber. Heatraili aeglus ei ole probleem, mille Heatrail peab lahendama enne, kui pood on kaitstud. Selleks ajaks, kui me märkaksime, on klient juba ootamise lõpetanud. Meie kättesaadavus on küsimus selle kohta, kui palju signaali pood saab, mitte kunagi küsimus selle kohta, kas ta saab müüa.

Sellest järgneb üks detail. Teek keeldub konstruktsioonil nullist ajalimiidist, sest aluseks olev HTTP klient loeb nulli kui ajalimiidi puudumist, ja pood, kes seadis nulli tähenduses piiramatu kannatlikkus, oleks eelarve märkamatult eemaldanud. Ta lükatakse konstruktsioonil tagasi, mitte ei võeta vastu ja ei tööta hiljem ümber. Sildistamine käitub tahtlikult vastupidi: kontroll ei tohi kunagi visata, ja silti ei tohi kunagi vaikselt kaotsi minna, seega ebaõnnestunud silt tõstab vea, mida poe järjekord saab uuesti proovida.

Joonis 1

Kutse Heatrailile on kõrvalharu eelarvega. Tee kassast makseteenuseni ei läbi teda kunagi.

Degradeerunud on kuju, mitte viga

Kui eelarve saab otsa, kui host ei lahendu, kui vastus ei ole 2xx või JSON on vigane, tagastab klient ühe kindla asja: ['degraded' => true, 'score' => 0, 'reasons' => []]. Null on seal sellepärast, et teatada ei ole midagi, mitte sellepärast, et tellimus oleks hinnatud ja puhastatud. Lugege degraded kui signaali puudumist selle tellimuse kohta. Ta ei tähenda kunagi madalat riski, ja ta ei ole kunagi erand, mida kassa peab püüdma.

Numbrid esimeselt tööpäevalt produktsioonis, 1. september 2026: ringkäigu mediaan 386 ms, 95. protsentiil 610 ms ja kõige aeglasem kontroll 799 ms 800 ms eelarve vastu. Ka päeva kõige aeglasem kontroll jõudis tagasi eelarve piires, ja kontroll, mis poleks jõudnud, oleks maksnud sellele tellimusele signaali, mitte müüki.

Samal päeval tegime harjutuse stagingus: Heatraili hosti DNS lahendus murtud tahtlikult, ost lõpetati, ja kontroll tagastas degraded 16 ms jooksul, seejärel tühjendas järjekorrast, kui teenus naasis. Kuusteist millisekundit ei ole mõõt, kui kiired me oleme. See on kulu sellest, et klient otsustab ise, et ta ei hakka ootama.

Kolm latentsusnumbrit on produktsioonimõõtmised. Arv 16 ms tuleb stagingu harjutusest. Kättesaadavus otsustab siin ainult seda, kui palju signaali pood saab, mitte seda, kas tema kassa töötab.

Joonis 2

Mõõdetud esimesel live päeval ja sama päeva katkestusharjutuses. Mõlemad rajad lõpevad samas kohas, ja ainult üks neist kannab signaali.

Kuidas kontrollida

Lugege klienti, mitte seda lehte. Ajalimiit on konstant avalikus teegis ja degradeerunud vastus on kindel massiiv, seega mõlemad väited on kahe grepiga teie enda kassas paika pandavad.

grep -n "DEFAULT_TIMEOUT_MS" src/HeatrailClient.php
grep -n "'degraded' => true" src/HeatrailClient.php

Seejärel tehke harjutus, mille me tegime. Suunake teek hostinimele, mis ei lahendu, ja lõpetage testost. Tellimus läheb läbi, kontroll tuleb tagasi degradeerununa, ja payload ootab kohalikus järjekorras. Kui mõni osa sellest teie liideses ei juhtu, on see viga ja me tahame sellest kuulda.

Õiguslik alus

Kuna Heatrail ei tee ühtegi otsust ja ostjale ei järgne vastusest üksi õiguslikku ega samaväärselt olulist mõju, ei ole vastus otsus GDPR artikli 22 tähenduses. Poe enda skoori käsitlemine, inimese või poe enda reeglite poolt, on koht, kus otsus tehakse, ja pood jääb selle vastutavaks töötlejaks. Vt andmetöötluslepingut ja turvamudelit.

Põhjused, mida saab lugeda, mida vastus kannab otsuse asemel, ja kes on mõeldud teda lugema.
Miks võrku ei saa loetleda, piiri teine pool: kutse, mida saab teha ainult tellimuse kohta, mis poel tegelikult on.
PHP teek, kus eelarve, järjekord ja degradeerunud kuju on kood, mida saate lugeda.