Çoxtenantlilik və idempotentlik

# 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-dir **çoxtenantlı**: bir giriş qapısı bir verilənlər bazasından bir çox iş sahəsinə xidmət edə bilər, onların məlumatlarını ayrı saxlayaraq. Bu təhlükəsizliyi təmin edən iki mexanizm var — **Postgres Sətir-Səviyyə Təhlükəsizliyi (RLS)** oxuma/yazma izolyasiyası üçün və bir **idempotentlik təbəqəsi** belə ki, təkrar cəhdlər və dönmə bərpası heç vaxt real dünya yan təsirini təkrarlamasın. **Səviyyə:** Sətir səviyyəli təhlükəsizlik çoxmüştərili izolyasiyası ödəmə ilə məhdudlaşdırılmışdır **Müəssisə** səviyyə — pulsuz/Cəmiyyət platformasının bir hissəsi deyil; idempotentlik təbəqəsi əsas hissənin bir hissəsidir. ## Sətir-Səviyyəli Təhlükəsizlik ilə Kirayəçi təcridi İzolasiya yalnız tətbiq kodunda deyil, verilənlər bazasında da tətbiq olunur. AiHummer sorğuları vasitəsilə işlədir **məhdudlaşdırılmış Postgres rolu** (`aihummer_app`) RLS siyasətləri tətbiq edilmişdir, buna görə verilənlər bazası öz-özünə aktiv tenant-a aid olmayan sətirləri rədd edir. RLS-dir **qoşulmaq**. Siz onu məhdud rol üçün ikinci əlaqə sətirini qapıya verərək aktivləşdirirsiniz: ```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] > Ev sahibi-yerli quraşdırmalar üçün quraşdırıcı təyin edir `AIHUMMER_DB_APP_URL` > avtomatik olaraq, buna görə RLS standart yerləşdirmədə varsayılan olaraq aktivdir. Əgər > dəyişən yoxdur, qapı yalnız sahib hovuzunda işləyir və RLS yoxdur > aktiv. ### Hər kirayəçiyə görə istiqamətləndirmə Məhdud rol daxilində, hər bir sorğu öz icarədarı ilə məhdudlaşdırılır: gateway əlaqədə cari icarədar kontekstini təyin edir ki, RLS siyasətləri düzgün iş sahəsinə görə həll olunsun. `WHERE tenant_id = …` Filtrlər hər yerdə əl ilə hazırlanmayıb; siyasət bunu mərkəzləşdirilmiş şəkildə tətbiq edir, bu isə o deməkdir ki, qaçırılmış filter başqa bir kirayəçinin sətirlərini sızdıra bilməz. ### Sistem / keçid rejimi Bəzi işlər qanuni olaraq kirayəçilərarasıdır — bütün instansiya üzrə fəaliyyət göstərən fon işçiləri, cədvəlçilər və texniki xidmət işləri. Bunlar bir **sistem / keçid rejimi** beləliklə onlar nəyə ehtiyacları olduğunu görə bilərlər. Bypass etibar olunan daxili işçilər üçün nəzərdə tutulub, sorğu idarə edən yollar üçün deyil. > [!WARNING] > **Miqrasiyalar həmişə sahib hovuzunda işləyir**, məhdudlaşdırılmış rol altında heç vaxt. > Sahib bağlantısının sxemi dəyişdirmək və RLS tətbiq etmək imtiyazları var > siyasətlər; məhdudlaşdırılmış rol qəsdən etmir. İki bağlantını saxlayın > sətirlər fərqlidir və verir `aihummer_app` Yalnız ona ehtiyacı olan rolu. ## İdempotent yan təsirlər Bir döngü real dünya yan təsirlərini yarada bilər: poçt göndərmək, bir kanala mesaj göndərmək. Əgər bir döngü təkrar olunarsa — müvəqqəti səhv səbəbindən, ya da qapıdan (gateway) döngünün ortasında yenidən başlaması və bərpa səbəbilə onu yenidən ifa etməsi — bu yan təsirlər mütləq **yox** iki dəfə baş verə bilər. AiHummer bunu iki əməkdaşlıq edən hissə ilə təmin edir. ### Yenidən davam edə bilən dəftər açarı Hər bir yan təsir qarşı tərəfə qeyd olunur **təkrar başlat-stabilləşdirilmiş dəftər açarı**: bir açar ki, növbədən deterministik olaraq əldə edilir, buna görə eyni növbənin təkrarı *eyni* açarı hesablamaqla nəticələnir, yeni bir açar deyil. Mühasibat kitabı hansı açarların artıq həyata keçirildiyini xatırlayır. ### Yan təsir baryeri Belə bir təsirdən əvvəl **poçt** və ya **kanal-göndər** icra olunur, o keçir **yan təsir baryeri** bu jurnalı yoxlayır. Əgər bu açar artıq işə düşübsə, maneə qısa dövrə yaradır və effekt atlanır; əks halda, effekt işləyir və açar təsdiqlənir. ```text side-effect requested └─▶ compute resume-stable ledger key └─▶ barrier: key already committed? ├─ yes ─▶ skip (no double-send) └─ no ─▶ perform effect ─▶ commit key ``` Nəticə budur **daxildə ən azı bir dəfə çatdırılma olmasına baxmayaraq tam olaraq bir dəfə xarici davranış**. Təkrar cəhdlər quruluş etibarilə təhlükəsizdir, bu da dönmə bərpasına imkan verir (bax [Etibarlı çatdırılma və bərpa](/az/v1.0/architecture/delivery-outbox)) kəsilmiş növbəni müştərinin eyni e-poçtu və ya eyni cavabı iki dəfə almadan təkrar oynayın. > [!TIP] > Buna görə AiHummer zəmanətli çatdırılma və avtomatik dönmə bərpası təklif edə bilər > adətən təkrarlanan mesajların riski olmadan — idarəolunaqlıq təməlidir > çatdırılma təminatları əsasında qurulub. ## Növbəti haradır - Bir dönüşü idarə edən iş vaxtı: [Şlüz və dönüş mühərriki](/az/v1.0/architecture/gateway-turn-engine). - Cavabların dəqiq olaraq bir dəfə necə qaytarıldığı: [Etibarlı çatdırılma və bərpa](/az/v1.0/architecture/delivery-outbox).