Uvnitř LIFT & FIT Private Space: jak sladit peníze, čas a skutečné dveře.

Private Space má schválně krátkou zákaznickou cestu. Vyberete výhradní čas, zaplatíte nebo použijete vstupový balíček, dostanete dočasný přístup, odcvičíte a odejdete. Implementace stejně lineární být nemůže. Koordinuje relační databázi, externí platební bránu, frontu úloh, e-mailovou službu a poskytovatele chytrého zámku. Žádná z těchto komponent neumí vstoupit do jedné společné transakce.

Technicky je to tedy méně kalendář a více kompaktní distribuovaný systém. Zajímavá otázka není, zda funguje běžný scénář. Zajímavé je, co se stane, když zákazník odešle platbu dvakrát, callback dorazí opakovaně, fronta po databázovém commitu neodpoví, platba se dokončí až po zrušení nebo se stará úloha pro odebrání přístupu probudí po přesunutí rezervace.

Doména je distribuovaná transakce bez společného commitu.

Žádná databázová transakce neumí atomicky zapsat místní rezervaci, zachytit peníze u externí brány, doručit e-mail a vytvořit přístupový údaj u poskytovatele zámku. Předstírat opak vede k rozdělené pravdě: zákazník zaplatil, ale rezervace se nepotvrdila; rezervace je potvrzená, ale úloha pro přístup chybí; termín je zrušený, ale starý PIN stále funguje.

Každá z těchto oblastí proto dostává vlastní stavový automat a databáze slouží jako trvanlivý koordinační bod. Práce mimo databázi se nejprve zapíše jako záměr a potom se opakuje nebo opravuje tak dlouho, dokud lokální a vzdálený stav nesouhlasí nebo nevznikne explicitní incident pro člověka.

Rezervace začíná řízením souběhu, ne validací formuláře.

Dva zákazníci mohou současně vybrat stejný termín. Jeden zákazník může současně odeslat stejnou objednávku dvakrát. Nejde o stejný souběžný konflikt. První je soutěž o vzácný zdroj; druhý vyžaduje idempotenci jednoho logického požadavku. Každý potřebuje vlastní pojistku.

Krátkodobý token z prohlížeče se před uložením převede na otisk se serverovým klíčem. Opakování se stejným tokenem vrátí existující rezervaci pouze tehdy, když stále odpovídá termín, kontext identity, počet osob i platební režim. Uvnitř transakce databázový zámek serializuje konkrétní pokus o objednávku, další zámek chrání termín a inventář vstupových balíčků se při čerpání zamyká samostatně.

Cena se zkopíruje do rezervace i platebního záznamu. Později se nečte z měnitelné konfigurace termínu. Stejný princip neměnného snímku platí pro podmínky, vlastnický kontext a interval přístupu. Budoucí změna nastavení nesmí zpětně přepsat význam rozběhnuté transakce.

# Redukovaný transakční kontrakt, nikoli produkční zdroj.
lock(checkout_attempt)
existing = booking_by_attempt(checkout_attempt)

if existing:
    require same_request(existing, request)
    return existing

lock(slot)
require slot.state == AVAILABLE

create booking(state=PENDING, price=snapshot(slot.price))
create payment(state=PENDING, amount=snapshot(slot.price))
update slot(state=HELD)
append outbox(RELEASE_IF_UNPAID)

commit

Platební callback je podnět ke kontrole, ne důkaz.

Návratová stránka v prohlížeči je součást uživatelského zážitku, nikoli hranice důvěry. Ani oznámení platební brány samo nestačí. Může přijít dvakrát, pozdě, mimo očekávaný kanál nebo ve chvíli, kdy se místní kontext změnil. Backend je používá jako signál k přímému serverovému načtení aktuálního detailu platby.

Ověření nejprve najde místní platební záznam, potom porovná částku a měnu s neměnným snímkem. Až pak přeloží vzdálený stav do místního platebního automatu. Přechody rezervace a termínu jsou podmíněné, takže opakovaný callback nemůže tutéž čekající rezervaci potvrdit dvakrát.

Druhá větev je snadno přehlédnutelná. Platba a zrušení závodí přes dva různé systémy. Pokud se peníze připíšou až po vypršení blokace nebo po zrušení rezervace, její vzkříšení by porušilo vlastnictví termínu. Bezpečný přechod vede do procesu vrácení peněz s viditelným mezistavem.

// Konceptuální reconciliation; provider detaily jsou vynechané.
const remote = await gateway.getPayment(providerPaymentId);

require(remote.amount === payment.amountSnapshot);
require(remote.currency === payment.currencySnapshot);

if (remote.state === "paid" && booking.state === "pending") {
  transaction(() => {
    payment.markPaid();
    booking.confirmIfPending();
    slot.bookIfHeld();
    outbox.append("provision-access", booking.id);
  });
} else if (remote.state === "paid" && booking.state === "cancelled") {
  transaction(() => {
    payment.markRefundPending();
    outbox.append("request-refund", payment.id);
  });
}

Outbox uzavírá mezeru mezi databázovým commitem a frontou.

Zapsat rezervaci a potom zavolat frontu vytváří okno, ve kterém databáze změnu potvrdí a volání fronty selže. Opačné pořadí problém pouze obrátí. Platforma proto zapisuje každou požadovanou externí akci jako řádek outboxu ve stejné databázové transakci jako doménovou změnu.

Výsledkem je doručení alespoň jednou, ne magické provedení právě jednou. Když odesílač spadne poté, co fronta úlohu přijala, ale před označením řádku outboxu, stejný deterministický identifikátor úlohy potlačí duplicitní odeslání. Příjemce přesto musí snést opakování, protože chyba může nastat až po přijetí operace externím poskytovatelem, ale před doručením odpovědi pracovnímu procesu.

Počet opakování je omezený. Trvale neplatná zpráva se má stát viditelnou selhanou událostí pro operátora, ne nesmrtelnou smyčkou. Řízená obnova může zvýšit generaci odeslání, aby starý neúspěšný záznam ve frontě neblokoval vědomé opakování.

domain transaction
  update booking and slot
  insert outbox(effect_id, queue, payload, retry_policy)
commit

dispatcher
  read pending outbox rows
  queue with job_id derived from effect_id
  mark dispatched after queue acknowledgement

consumer
  verify current domain state
  perform an idempotent or recoverable effect

Fyzický přístup musí odmítnout zastaralou práci.

Přístup se nejdříve naplánuje místně a až potom aktivuje u poskytovatele. Plán spojuje rezervaci, termín, interval platnosti, oprávnění a konkrétní záznam o jeho vytvoření. Citlivý přístupový údaj je po dobu potřeby šifrovaný v úložišti a po odebrání se odstraní. Identifikátor poskytovatele zůstává oddělený od údaje, který vidí zákazník.

Plánovat lze brzy; aktivovat až v povoleném okně.

Potvrzená rezervace může mít trvanlivě uložený záměr přístupu, aniž by vzdálené oprávnění zůstalo aktivní déle, než je nutné.

Po nejasném timeoutu se nejprve hledá stabilní identita.

Pokud mohl poskytovatel požadavek přijmout před vypršením času, pracovní proces hledá jednu přesnou shodu podle stabilního aliasu. Nula shod a více shod jsou dva různé chybové stavy. Slepé opakování vytvoření by mohlo založit druhé oprávnění.

Vzdálený úspěch se uloží jen pro stále platnou rezervaci.

Rezervace musí zůstat potvrzená, termín obsazený a identifikátor oprávnění spolu s intervalem platnosti beze změny. Pokud mezitím proběhlo zrušení nebo přesun, nově vytvořené vzdálené oprávnění se odstraní.

Každá destruktivní úloha nese stav, který očekává zničit.

Oprávnění, záznam o jeho vytvoření, identifikátor u poskytovatele i interval platnosti se před smazáním porovnají. Odebrání ze starého rozvrhu nesmí odstranit náhradní oprávnění pro nový čas.

Nejostřejší invariant přichází při zrušení a přesunu. Pokud už zákazník přístupový údaj viděl, starý termín se okamžitě nevrátí do prodeje. Přesune se do stavu closed, dokud poskytovatel nepotvrdí odebrání. Dočasně obětujeme dostupnost, protože prodat interval, ve kterém může starý PIN stále fungovat, je fyzický bezpečnostní problém, ne drobné zpoždění.

Provoz je součást modelu konzistence.

Některé rozpory nelze opravit bezpečně bez kontextu. Provozní dohled proto hledá zastaralé platební stavy, selhané řádky outboxu, plány přístupu po aktivačním okně, oprávnění čekající na odebrání a rozdíly mezi místním a vzdáleným inventářem. Bezpečné opravy jsou omezené a idempotentní; nejasný případ se ukáže operátorovi i s auditní stopou.

E-mail má vlastní nejasnost. Vypršení síťového času po přijetí zprávy poskytovatelem není totéž co jisté selhání. Slepý přechod k druhému poskytovateli může doručit dva e-maily s přístupem. Pokus o doručení proto potřebuje stabilní klíč, trvanlivý stav a pravidlo pro výsledek, který mohl uspět.

Admin není jen CRUD. Je to provozní pohled na stavové přechody: která komponenta právě vlastní pravdu, který efekt čeká, co lze bezpečně zopakovat a co vyžaduje vědomé rozhodnutí člověka.

Pět lekcí, které platí i mimo rezervační software.

1. Nezávislé pravdy modelujte nezávisle.

Rezervace, platba, dostupnost a přístup nepatří do jednoho pohodlného stavového pole. Jejich nesouhlas jsou přesně ty chybové stavy, které systém potřebuje zobrazit.

2. Idempotence zahrnuje ekvivalenci požadavku.

Vrátit pro opakovaný klíč libovolný objekt není bezpečné. Opakování musí popisovat stejný logický požadavek, jinak jde o konflikt.

3. Záměr externí akce uložte spolu se změnou stavu.

Transakční outbox změní nespolehlivé volání služby na trvanlivou práci, kterou lze sledovat, opakovat a auditovat.

4. Opakování potřebuje identitu i ověřitelný výsledný stav.

Vypršení času u poskytovatele znamená neznámý výsledek. Stabilní vzdálená identita a místní kontrola výsledku dělají obnovu bezpečnější než slepé opakování.

5. Kde software ovládá fyzický svět, selhávejte zavřeně.

Dočasná nedostupnost je lepší než znovu prodat přístup, jehož revokace není jistá. Dostupnost produktu a bezpečnost neoptimalizují vždy stejným směrem.

Co záměrně nepublikujeme.

Článek neobsahuje přístupové údaje poskytovatelů, materiál pro ověření callbacků, identifikátory zámků nebo zařízení, formát přístupových údajů, šifrovací klíče, surové platební zprávy, produkční trasy, zákaznická data, adresy infrastruktury, přesné provozní prahy ani postupy obnovy. Ukázky jsou zkrácené kontrakty napsané pro článek, ne zdrojový kód.

Přenositelná hodnota je v invariantech: místní neměnný snímek před externí prací, podmíněné stavové přechody, serverové ověření platby, trvanlivý záměr externí akce, odmítnutí zastaralé úlohy a explicitní nejistota při nejasném výsledku poskytovatele.

Další krok je silnější důkaz korektnosti.

Nejhodnotnější pokračování není další prvek v přehledu. Jsou to generativní testy pro proložené události platby a zrušení, modelové testy stavů rezervace a přístupu, kontraktní testy nejasných timeoutů u poskytovatelů a monitory změn, které rozdíl vysvětlují, ne pouze počítají.

Systém tohoto typu se stává důvěryhodným tím, že špatné stavy umí zobrazit, detekovat a opravit. Zákazník nemá poznat, že callback závodil se zrušením nebo že pracovní proces restartoval mezi dvěma zápisy. Architektura existuje právě proto, aby takové události zůstaly inženýrským problémem a nezměnily se v zamčené dveře na začátku zaplaceného termínu.