Flerbrukerarkitektur og idempotens

# gateway.env
# Owner pool — runs migrations and privileged maintenance
AIHUMMER_DATABASE_URL=postgres://aihummer:***@localhost:5432/aihummer?sslmode=disable
# Restricted role — activates RLS for normal request traffic
AIHUMMER_DB_APP_URL=postgres://aihummer_app:***@localhost:5432/aihummer?sslmode=disable

side-effect requested
   └─▶ compute resume-stable ledger key
         └─▶ barrier: key already committed?
               ├─ yes ─▶ skip (no double-send)
               └─ no  ─▶ perform effect ─▶ commit key

AiHummer er **multileietaker**: én gateway kan betjene mange arbeidsområder fra én database samtidig som den holder dataene deres adskilt. To mekanismer gjør det trygt — **Postgres radnivå-sikkerhet (RLS)** for lese-/skriveisolasjon, og en **idempotenslag** slik at gjentakelser og svinggjenoppretting aldri dupliserer en reell bivirkning. **Tier:** Radnivå-sikkerhet multitenant-isolasjon er begrenset av det betalte **Foretak** nivå — ikke en del av den gratis/Community-plattformen; idempotenslaget er en del av kjernen. ## Leietakerisolasjon med radnivåsikkerhet Isolasjon håndheves på databasen, ikke bare i applikasjonskode. AiHummer kjører spørringer gjennom en **begrenset Postgres-rolle** (`aihummer_app`) som har RLS-retningslinjer anvendt, slik at databasen selv avviser rader som ikke tilhører den aktive leietakeren. RLS er **meld deg på**. Du aktiverer det ved å gi gatewayen en annen tilkoblingsstreng for den begrensede rollen: ```ini # gateway.env # Owner pool — runs migrations and privileged maintenance AIHUMMER_DATABASE_URL=postgres://aihummer:***@localhost:5432/aihummer?sslmode=disable # Restricted role — activates RLS for normal request traffic AIHUMMER_DB_APP_URL=postgres://aihummer_app:***@localhost:5432/aihummer?sslmode=disable ``` > [!NOTE] > For verts-native installasjoner setter installasjonsprogrammet `AIHUMMER_DB_APP_URL` > automatisk, så RLS er på som standard i en standard distribusjon. Hvis > variabelen er fraværende, gatewayen kjører kun på eierpoolen og RLS er ikke > aktiv. ### Per-leietaker avgrensning Innenfor den begrensede rollen er hver forespørsel knyttet til sin leietaker: gatewayen setter den nåværende leietakers kontekst på tilkoblingen slik at RLS-policyene løses mot riktig arbeidsområde. `WHERE tenant_id = …` filtre rulles ikke for hånd overalt; policyen håndheves sentralt, noe som betyr at et oversett filter ikke kan lekke en annen leietakers rader. ### System / omgåelsesmodus Noe arbeid er legitimt tverr-leietaker — bakgrunnsarbeidere, planleggere og vedlikeholdsoppgaver som opererer på tvers av hele instansen. Disse kjører i en **system / omgåelsesmodus** slik at de kan se hva de trenger å se. Bypass er reservert for betrodde interne arbeidere, ikke for forespørselshåndteringsstier. > [!WARNING] > **Migrasjoner kjører alltid på eierpoolen**, aldri under den begrensede rollen. > Eierforbindelsen har rettigheter til å endre skjema og bruke RLS > retningslinjer; den begrensede rollen gjør det bevisst ikke. Hold de to tilkoblingene > strenger distinkte og gi `aihummer_app` rolle bare det den trenger. ## Idempotente bivirkninger En runde kan produsere bivirkninger i den virkelige verden: sende e-post, poste en melding tilbake til en kanal. Hvis en runde prøves på nytt — på grunn av en midlertidig feil, eller fordi gatewayen startet på nytt midt i runden og gjenoppretting spoler den tilbake — må disse bivirkningene **ikke** skje to ganger. AiHummer garanterer dette med to samarbeidende deler. ### En CV-stabil hovedboknøkkel Hver bivirkning blir registrert mot en **gjenoppta-stabil hovedboknøkkel**: en nøkkel som er avledet deterministisk fra turen, slik at en gjentakelse av samme tur beregner den *samme* nøkkelen i stedet for en ny. Regnskapet husker hvilke nøkler som allerede har blitt handlet på. ### En bivirkningsbarriere Før en effekt som **post** eller **kanal-send** utføres, passerer det gjennom en **bivirkning barriere** som sjekker hovedboken. Hvis denne nøkkelen allerede har blitt utløst, kortsluttes barrieren og effekten blir hoppet over; hvis ikke, kjører effekten og nøkkelen blir bekreftet. ```text side-effect requested └─▶ compute resume-stable ledger key └─▶ barrier: key already committed? ├─ yes ─▶ skip (no double-send) └─ no ─▶ perform effect ─▶ commit key ``` Resultatet er **nøyaktig-en-gang ekstern oppførsel selv om levering er minst-en-gang internt**. Gjentakelser er trygge av natur, noe som gjør at det tillater gjenoppretting av vending (se [Pålitelig levering og gjenoppretting](/no/v1.0/architecture/delivery-outbox)) gjenta en avbrutt runde uten at en kunde mottar den samme e-posten eller det samme svaret to ganger. > [!TIP] > Dette er grunnen til at AiHummer kan tilby garantert levering og automatisk returhåndtering > uten den vanlige risikoen for dupliserte meldinger — idempotens er grunnlaget > leveringsgarantiene bygger på. ## Hvor til neste - Kjøretiden som driver en vending: [Gateway og svingemotor](/no/v1.0/architecture/gateway-turn-engine). - Hvordan svar blir returnert nøyaktig én gang: [Pålitelig levering og gjenoppretting](/no/v1.0/architecture/delivery-outbox).