Çok kiracılılık ve değiştirilemezlik

# 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 şudur **çok kiracılı**: bir geçit, verilerini ayrı tutarken bir veritabanından birçok çalışma alanına hizmet edebilir. Bunu güvenli hale getiren iki mekanizma vardır — **Postgres Satır Düzeyinde Güvenlik (RLS)** okuma/yazma izolasyonu için ve bir **idempotans katmanı** böylece yeniden denemeler ve dönüş kurtarma, gerçek dünyadaki bir yan etkiyi asla çoğaltmaz. **Seviye:** Satır Seviyesi Güvenliği çok kiracılı izolasyon, ücretli olan tarafından sınırlandırılmıştır **Girişim** katman — ücretsiz/Topluluk platformunun bir parçası değil; tekilleştirme katmanı çekirdeğin bir parçasıdır. ## Satır Düzeyinde Güvenlik ile Kiracı İzolasyonu İzolasyon yalnızca uygulama kodunda değil, veritabanında da zorlanır. AiHummer sorguları aracılığıyla çalıştırır **kısıtlı Postgres rolü** (`aihummer_app`) RLS politikaları uygulanmış olan, dolayısıyla veritabanının kendisinin aktif kiracıya ait olmayan satırları reddettiği. RLS şudur **katılmak**. Bunu, geçide kısıtlı rol için ikinci bir bağlantı dizesi vererek etkinleştirirsiniz: ```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] > Ana bilgisayar-yerel kurulumlar için yükleyici ayarlar `AIHUMMER_DB_APP_URL` > otomatik olarak, bu nedenle standart bir dağıtımda RLS varsayılan olarak açıktır. Eğer > Değişken yoksa geçit yalnızca sahip havuzda çalışır ve RLS değil > aktif. ### Kiracı başına kapsamlandırma Kısıtlı rol kapsamında, her istek kendi kiracısına göre sınırlandırılmıştır: geçit, bağlantıda mevcut kiracı bağlamını ayarlar, böylece RLS politikaları doğru çalışma alanına göre çözülür. `WHERE tenant_id = …` Filtreler her yerde elle yapılmaz; politika bunu merkezi olarak uygular, bu da kaçırılmış bir filtrenin başka bir kiracının satırlarını sızdıramayacağı anlamına gelir. ### Sistem / atlama modu Bazı işler meşru bir şekilde kiracılar arasıdır — tüm örnek üzerinde çalışan arka plan işçileri, zamanlayıcılar ve bakım görevleri. Bunlar bir **sistem / atlatma modu** böylece neye ihtiyaç duyduklarını görebilirler. Atlatma sadece güvenilen dahili çalışanlar için ayrılmıştır, istek işleme yolları için değil. > [!WARNING] > **Göçler her zaman sahip havuzunda çalışır**, asla kısıtlı rolde değil. > Sahip bağlantısı, şemayı değiştirme ve RLS uygulama ayrıcalıklarına sahiptir > politikalar; kısıtlı rol bilerek yapmaz. İki bağlantıyı koruyun > farklı dizeler ve vermek `aihummer_app` sadece ihtiyacı olan rol. ## İdempotent yan etkiler Bir dönüş gerçek dünya yan etkileri üretebilir: e-posta göndermek, bir kanala mesaj göndermek gibi. Eğer bir dönüş yeniden denenirse — geçici bir hata nedeniyle ya da geçit ortasında yeniden başlatıldığı ve kurtarma nedeniyle tekrar oynatıldığı için — bu yan etkiler **değil** iki kez meydana gelir. AiHummer bunu iki işbirliği yapan parça ile garanti eder. ### Özgeçmiş-stabil defter anahtarı Her yan etki bir şeye karşı kaydedilir **devam et-stabil defter anahtarı**: turdan deterministik olarak türetilen bir anahtar, böylece aynı turun yeniden oynanması *aynı* anahtarı hesaplar, yeni bir anahtar değil. Defter hangi anahtarların zaten işlem gördüğünü hatırlar. ### Yan etki bariyeri Böyle bir etki oluşmadan önce **posta** veya **kanal-gönder** uygulanır, bir ... üzerinden geçer **yan etki bariyeri** defteri kontrol eden bu. Eğer bu anahtar zaten tetiklenmişse, bariyer kısa devre yapar ve etki atlanır; eğer değilse, etki çalışır ve anahtar işlenir. ```text side-effect requested └─▶ compute resume-stable ledger key └─▶ barrier: key already committed? ├─ yes ─▶ skip (no double-send) └─ no ─▶ perform effect ─▶ commit key ``` Sonuç şudur **teslimat dahili olarak en az bir kez olsa bile dış davranış tam olarak bir kez**. Yeniden denemeler tasarım itibariyle güvenlidir, bu da dönüş kurtarmasına izin verir (bkz [Güvenilir teslimat ve kurtarma](/tr/v1.0/architecture/delivery-outbox)) müşterinin aynı e-postayı ya da aynı yanıtı iki kez almadan kesintiye uğramış bir turu tekrar oynayın. > [!TIP] > İşte bu yüzden AiHummer garantili teslimat ve otomatik dönüş kurtarması sunabilir > olağan tekrar mesaj riski olmadan — idempotans temelidir > teslimat garantileri üzerine inşa edilmiştir. ## Sonra nereye? - Bir dönüşü çalıştıran çalışma zamanı: [Geçit ve dönüş motoru](/tr/v1.0/architecture/gateway-turn-engine). - Yanıtların tam olarak bir kez nasıl döndürüldüğü: [Güvenilir teslimat ve kurtarma](/tr/v1.0/architecture/delivery-outbox).