Kod yazmadan backend için çok kiracılı SaaS veri modeli seçenekleri

Sorun: kiracıları ayırırken hızı düşürmemek

Çok kiracılılık, tek bir yazılım ürününün birçok müşteriye (kiracıya) hizmet vermesi demektir ve her kiracının yalnızca kendi verisini görmesi gerekir. Zor olan kısmı bunu tutarlı şekilde uygulamaktır: sadece bir ekranda değil, her API çağrısında, yönetici panelinde, ihracatta ve arka plan işinde.

Veri modeliniz günlük operasyonları birçok ekipten daha fazla etkiler. İzinleri, raporlamayı, büyüdükçe sorgu hızını ve “küçük” bir hatanın ne kadar riskli olabileceğini şekillendirir. Bir filtreyi kaçırırsanız veri sızdırabilirsiniz. Çok izole ederseniz raporlama çileye dönüşür.

Çok kiracılı SaaS veri modelini yapılandırmanın üç yaygın yolu vardır:

• Her tablonun tenant_id içerdiği tek bir veritabanı
• Bir veritabanı içinde kiracı başına ayrı şemalar
• Her kiracı için ayrı veritabanları

Kod yazmadan bir backend ile tasarım yapsanız bile aynı takaslar geçerlidir. AppMaster gibi araçlar tasarımınızdan gerçek backend kodu ve veritabanı yapıları ürettiğinden, erken modelleme kararları üretimde performans ve davranış olarak hızlıca ortaya çıkar.

Bir yardım masası (helpdesk) aracını düşünün. Her ticket satırında tenant_id varsa “tüm açık ticket'ler” sorgulamak kolaydır, ama her yerde kiracı kontrollerini zorunlu kılmanız gerekir. Her kiracıya ayrı şema veya veritabanı verirseniz izolasyon varsayılan olarak daha güçlüdür, ama tüm kiracılara yönelik raporlama (ör. "ortalama kapanma süresi") daha zahmetli hale gelir.

Amaç, raporlama, destek ve büyümeye sürtünme eklemeden güvenebileceğiniz bir ayrım sağlamaktır.

Hızlı seçim yolu: daraltan 4 soru

Veritabanı teorisiyle başlamayın. Ürünün nasıl kullanılacağını ve haftalık olarak neye ihtiyaç duyacağınızı düşünün.

Cevabı genellikle belirgin kılan dört soru

1. Veri ne kadar hassas ve katı kurallara tabi misiniz? Sağlık, finans ve katı müşteri sözleşmeleri genellikle daha güçlü izolasyon (ayrı şema veya ayrı veritabanı) gerektirir. Bu riski azaltır ve denetimleri kolaylaştırır.

2. Sık sık çapraz-kiracı raporlama yapmanız gerekiyor mu? "Tüm müşteriler" metriklerine (kullanım, gelir, performans) düzenli olarak ihtiyacınız varsa, tenant_id'li tek veritabanı genellikle en basitidir. Ayrı veritabanları bunu zorlaştırır çünkü birçok yerden veri çekip birleştirmeniz gerekir.

3. Kiracılar birbirinden ne kadar farklı olacak? Kiracılar özel alanlar, özel iş akışları veya benzersiz entegrasyonlar gerektiriyorsa, ayrı şemalar veya veritabanları değişikliklerin taşmasını azaltabilir. Çoğu kiracı aynı yapıyı paylaşıyorsa tenant_id temiz kalır.

4. Ekibinizin gerçekte işletmeye devam etmek için kapasitesi ne? Daha fazla izolasyon genelde daha fazla iş demektir: daha fazla yedek, daha fazla göç, daha fazla hareketli parça ve hataların saklanacağı daha fazla yer.

Pratik bir yaklaşım, en iyi iki seçeneğinizi prototiplemek ve sonra gerçek acı noktalarını test etmek: izin kuralları, raporlama sorguları ve model değiştikçe güncellemelerin nasıl yayıldığı.

Yaklaşım 1: Her satırda tenant_id olan tek veritabanı

Bu en yaygın kurulumdur: tüm müşteriler aynı tabloları paylaşır ve her kiracıya ait kayıtlarda tenant_id bulunur. Operasyonel olarak basittir çünkü tek bir veritabanı ve tek bir göç seti çalıştırırsınız.

Kural nettir: bir satır bir kiracıya aitse, tenant_id içermelidir ve her sorgu bunu filtrelemelidir. Kiracıya ait tablolar genellikle kullanıcılar, roller, projeler, ticket'lar, faturalar, mesajlar, dosya meta verileri ve kiracı verilerini birbirine bağlayan join tablolarıdır.

Sızıntıları azaltmak için tenant_id'yi vazgeçilmez yapın:

• Kiracıya ait tablolarda tenant_id zorunlu (NOT NULL) olsun
• İndeksleri tenant_id ile başlayan şekilde ekleyin (ör. tenant_id, created_at)
• Benzersizlik kuralları tenant_id'yi içersin (ör. her kiracı için benzersiz e-posta)
• tenant_id'yi her API ve iş akışında, sadece UI formlarında değil, aktarın
• Bunu yalnızca istemci tarafı filtrelerinde değil, backend'de zorunlu kılın

PostgreSQL'de satır düzeyi güvenlik (row-level security) politikaları, özellikle sorgular dinamik olarak oluşturuluyorsa güçlü bir güvenlik ağı ekleyebilir.

Referans verileri genellikle iki gruptan birine girer: tenant_id olmayan paylaşılan tablolar (ör. countries) ve tenant_id içeren kiracı kapsamlı kataloglar (ör. özel etiketler veya pipeline'lar).

AppMaster ile inşa ediyorsanız, çoğu olayı önleyen basit bir alışkanlık vardır: authenticated (doğrulanmış) kullanıcının kiracısından tenant_id'yi Business Process mantığında herhangi bir create veya read işleminden önce ayarlayın ve bu deseni tutarlı tutun.

İzinler etkisi: yaklaşımda neler değişir

İzinler, çok kiracılılığın başarılı olduğu ya da başarısız olduğu yerdir. Seçtiğiniz veri düzeni, kullanıcıları nasıl sakladığınızı, sorguları nasıl sınırladığınızı ve yönetici ekranlarında nasıl "oops" anlarından kaçındığınızı değiştirir.

Tek veritabanı ve her satırda tenant_id ile, ekipler genellikle tek bir Paylaşılan Users tablosu kullanır ve her kullanıcıyı bir kiracıya ve bir veya daha fazla role bağlar. Büyük kural aynıdır: her okuma ve yazma kiracı kapsamını içermelidir, küçük tablolar için bile (ayarlar, etiketler, loglar vb.).

Ayrı şemalarda genellikle kimlik doğrulama katmanı (login, parola, MFA) paylaşılan bir yerde tutulur, kiracı verileri ise kiracı başına bir şemada yaşar. İzinler kısmen yönlendirme problemi olur: uygulama, iş mantığı çalışmadan önce sorguları doğru şemaya yönlendirmelidir.

Ayrı veritabanlarında izolasyon en güçlüdür, ancak izin mantığı altyapıya kayar: doğru veritabanı bağlantısını seçmek, kimlik bilgilerini yönetmek ve "global" personel hesaplarını ele almak gerekir.

Üç yaklaşımda da birkaç desen kiracılar arası riski tutarlı şekilde azaltır:

• tenant_id'yi oturumda veya kimlik belirteci (auth token) iddialarında (claims) koyun ve bunu zorunlu kabul edin.
• Kiracı kontrollerini tek bir yerde (middleware veya tek bir paylaşılan Business Process) merkezileştirin, uç noktalara yaymayın.
• Yönetici araçlarında kiracı bağlamını açıkça gösterin ve kasıtlı bir kiracı geçişi isteyin.
• Destek erişimi için taklit (impersonation) kullanın ve bir denetim günlüğü (audit log) tutun.

AppMaster'da bu genellikle doğrulamadan hemen sonra kiracı bağlamını depolamak ve bunu API uç noktalarında ve Business Process'lerde yeniden kullanmak anlamına gelir; böylece her sorgu kapsamlı kalır. Bir destek görevlisi ancak uygulama kiracı bağlamını ayarladıktan sonra siparişleri görebilmelidir, UI yanlışlıkla filtrelediği için değil.

Tenant_id modelinde raporlama ve performans

tenant_id tek veritabanı yaklaşımı ile raporlama genelde basittir. Global panolar (MRR, kayıtlar, kullanım) herkes üzerinde tek bir sorgu çalıştırır; kiracı düzeyindeki rapor aynı sorgunun filtrelenmiş halidir.

Takas zamanla performanstadır. Tablolar büyüdükçe, yoğun bir kiracı "gürültülü komşu" haline gelerek daha fazla satır ve yazma üretebilir ve ortak sorguları yavaşlatabilir.

İndeksleme bu modeli sağlıklı tutar. Çoğu kiracıya özel okuma, tenant_id ile başlayan bir indeks kullanabilmelidir; böylece veritabanı doğrudan o kiracı dilimine atlayabilir.

İyi bir temel:

• tenant_id ilk sütun olacak şekilde birleşik (composite) indeksler ekleyin (ör. tenant_id + created_at, tenant_id + status, tenant_id + user_id)
• Gerçekten global indeksleri yalnızca çapraz-kiracı sorgular gerektiğinde tutun
• tenant_id'yi unutan joinler ve filtrelere dikkat edin; bunlar yavaş taramalara neden olabilir

Saklama ve silme politikaları da plan gerektirir çünkü bir kiracının geçmişi herkes için tabloları şişirebilir. Kiracıların farklı tutma politikaları varsa, kiracı bazlı planlı arşivleme veya tenant_id anahtarına göre arşiv tabloları kullanmayı düşünün.

Yaklaşım 2: Kiracı başına ayrı şemalar

Ayrı şemalarda hâlâ bir PostgreSQL veritabanı kullanırsınız, ancak her kiracıya kendi şeması (ör. tenant_42) verilir. O şema içindeki tablolar yalnızca o kiracıya aittir. Bu, her müşteriye "mini bir veritabanı" vermek gibi hissettirir, ancak birçok veritabanı çalıştırma yükü olmadan.

Yaygın kurulum, paylaşılan hizmetleri bir shared schema'da tutmak ve kiracı verilerini kiracı şemalarında saklamaktır. Ayrım genellikle hangi verilerin tüm müşteriler arasında paylaşılması gerektiği ve hangilerinin asla karışmaması gerektiği ile ilgilidir.

Tipik ayrım:

• Paylaşılan şema: tenants tablosu, planlar, faturalama kayıtları, feature flag'ler, denetim ayarları
• Kiracı şeması: siparişler, ticket'lar, envanter, projeler, özel alanlar gibi iş tabloları
• Duruma bağlı (ürüne göre): kullanıcılar ve roller, özellikle kullanıcılar birden fazla kiracıya erişebiliyorsa

Bu model, tablolar farklı ad alanlarında olduğu için kiracılar arası join riskini azaltır. Ayrıca bir şemayı hedefleyerek tek bir kiracıyı yedeklemek veya geri yüklemek kolaylaşabilir.

Göçler (migrations) ekipleri şaşırtan kısımdır. Yeni bir tablo veya sütun eklediğinizde, değişikliği her kiracı şemasına uygulamanız gerekir. 10 kiracı ile yönetilebilir; 1.000 ile şema sürümlerini takip etmeniz, göçleri partiler halinde çalıştırmanız ve tek bir bozuk kiracının geri kalanını engellememesi için güvenli başarısızlık yolları oluşturmanız gerekir.

Kimlik doğrulama ve faturalama gibi paylaşılan servisler genellikle kiracı şemalarının dışında tutulur. Pratik bir desen, paylaşılan auth (tek bir kullanıcı tablosu ile kiracı üyelik tablosu) ve paylaşılan faturalama (Stripe müşteri ID'leri, faturalar) iken, kiracı şemaları iş verilerini tutar.

AppMaster kullanıyorsanız, Data Designer modellerinin paylaşılan vs kiracı şemalarına nasıl eşleneceğini erkenden planlayın ve küresel servisleri stabil tutun ki kiracı şemaları giriş veya ödemeleri bozmasın.

Ayrı şemalarla raporlama ve performans

Ayrı şemalar, saf tenant_id filtrelemeye göre varsayılan olarak daha güçlü ayrım sağlar çünkü tablolar fiziksel olarak ayrıdır ve şema bazlı izinler kullanılabilir.

Eğer çoğu rapor kiracı bazlıysa raporlama harikadır. Sorgular basit kalır çünkü sürekli paylaşılan tabloları filtrelemek zorunda kalmazsınız. Bu model, bazı kiracıların ekstra tablolar veya özel sütunlar gerektirdiği durumlarda diğerlerini etkilemeden özelleştirme imkânı verir.

Ancak tüm kiracılara yönelik toplu raporlama şemaların handikapıdır: çok sayıda şemayı sorgulayabilen bir raporlama katmanı ya da her kiracıdan gece rollup'ları toplayan merkezi özet tablolar gerekir.

Yaygın desenler:

• Kiracı başına panolar yalnızca o kiracının şemasını sorgular
• Her kiracıdan gece rollup'ları alan merkezi bir analitik şema
• Veriyi veri ambarına uygun formata kopyayan dışa aktarma (export) işleri

Performans genelde kiracı düzeyli iş yükleri için iyidir. İndeksler her kiracıda daha küçük olur ve bir şemadaki yoğun yazma diğerlerini daha az etkiler. Takas operasyonel yük: yeni bir kiracı sağlarken şema oluşturma, göçleri çalıştırma ve şemaları hizada tutma gerekir.

Şemalar, tenant_id'ye göre daha sıkı izolasyon istendiğinde veya kiracı başına özelleştirme bekleniyorsa iyi bir uyum sağlar.

Yaklaşım 3: Kiracı başına ayrı veritabanı

Her kiracıya ayrı bir veritabanı vermek, her müşterinin kendi veritabanına sahip olması demektir (aynı sunucuda da olabilir). Bu en izole seçenek: bir kiracının verisi bozulsa veya ağır yük altına girse diğerlerini etkileme olasılığı çok düşüktür.

Bu, düzenlemeye tabi ortamlar (sağlık, finans, devlet) veya katı ayrım, özel saklama kuralları veya tahsisli performans bekleyen kurumsal müşteriler için uygundur.

Onboarding bir provisioning iş akışı haline gelir. Yeni bir kiracı kaydolduğunda sisteminiz bir veritabanı oluşturmalı veya klonlamalı, temel şemayı uygulamalı (tablolar, indeksler, kısıtlar), kimlik bilgilerini güvenli şekilde saklamalı ve API çağrılarını doğru veritabanına yönlendirmelidir.

AppMaster ile inşa ediyorsanız, ana tasarım kararı kiracı dizininin nerede tutulacağıdır (kiracı -> veritabanı bağlantısı haritası) ve her isteğin doğru bağlantıyı kullandığından nasıl emin olacağınızdır.

Güncellemeler ve göçler ana takastır. Şema değişikliği artık "bir kere çalıştır" değil, "her kiracı için çalıştır" demektir. Bu operasyonel iş ve risk ekler, bu yüzden ekipler genellikle şema sürümlendirir ve her kiracı için ilerlemeyi takip eden kontrollü göç işleri yürütür.

Artısı kontroldür. Büyük kiracıları önce taşıyabilir, performansı izleyebilir ve değişiklikleri kademeli olarak yayabilirsiniz.

Ayrı veritabanlarıyla raporlama ve performans

Ayrı veritabanları mantıksal olarak en basit olandır. Kazara çapraz-kiracı okumaları daha az olasıdır ve izin hatası genellikle yalnızca bir kiracıyı etkiler.

Performans güçlendirir. Yoğun sorgular, büyük içe aktarmalar veya bir kiracıdaki kaçan rapor Tenant A'yı yavaşlatırken Tenant B etkilenmez. Bu gürültülü komşuya karşı güçlü koruma sağlar ve kaynakları kiracı bazında ayarlamanıza izin verir.

Takas raporlarda ortaya çıkar. Global analitik en zor kısımdır çünkü veri fiziksel olarak dağılmıştır. Pratikte işe yarayan desenler: önemli olayları veya tabloları merkezi bir raporlama veritabanına kopyalamak, olayları bir ambar veri kümesine göndermek, kiracı başına rapor çalıştırıp sonuçları birleştirmek (kiracı sayısı küçükse) ve ürün metriklerini müşteri verilerinden ayırmak.

Operasyonel maliyet diğer büyük faktördür. Daha fazla veritabanı daha fazla yedek, yükseltme, izleme ve müdahale demektir. Ayrıca bağlantı sınırlarına daha çabuk ulaşabilirsiniz çünkü her kiracı kendi bağlantı havuzunu isteyebilir.

Veri sızıntısına veya ileride sorunlara yol açan yaygın hatalar

Çoğu çok kiracılı sorun "büyük tasarım" hatası değildir. Küçük ihmal ve eksikliklerin büyümesidir: güvenlik açıkları, dağınık raporlama ve pahalı temizlik işleri. Çok kiracılılık, sonradan eklenen bir özellik değil, bir alışkanlık olarak ele alındığında işler yolunda gider.

Yaygın bir sızıntı, user_roles, invoice_items veya etiketler gibi join tablolarında kiracı alanının unutulmasıdır. Her şey düzgün görünürken bir rapor veya arama bu tablo üzerinden join yapınca başka kiracıların satırlarını çekebilir.

Bir diğer sık problem, yönetici panellerinin kiracı filtrelerini atlamasıdır. Genelde "sadece destek için" diye başlar sonra tekrar tekrar kullanılır. No-code araçlar burada riski değiştirmez: her sorgu, iş süreci ve uç nokta aynı kiracı kapsamına ihtiyaç duyar.

ID'ler de sorun çıkarabilir. İnsan dostu ID'leri kiracılar arasında paylaşıyorsanız (ör. order_number = 1001) ve bunların global benzersiz olduğunu varsayıyorsanız, destek araçları ve entegrasyonlar kayıtları karıştırır. Kiracı kapsamlı kimlikleri dahili birincil anahtarlardan ayırın ve aramalarda kiracı bağlamını dahil edin.

Son olarak, ekipler ölçeklendikçe göçler ve yedeklemeleri hafife alır. 10 kiracı ile kolay olan bir şey 1.000 ile yavaş ve riskli hale gelir.

Hemen çoğu acıyı önleyen hızlı kontroller:

• Her tablonun kiracı sahipliğini açık yapın, join tablolar dahil.
• Tek bir kiracı kapsamı desenini kullanın ve her yerde yeniden kullanın.
• Raporlar ve dışa aktarmalar kiracı kapsamı olmadan çalışmasın (gerçekten global değilse).
• API'lerde ve destek araçlarında kiracı belirsiz kimliklerden kaçının.
• Geri yükleme ve göç adımlarını büyümeden önce uygulayın ve prova edin.

Örnek: bir destek görevlisi "invoice 1001" araması yapar ve sorgu kiracı kapsamını atladığı için yanlış kiracıdan veri çeker. Küçük bir hata, büyük etki yaratır.

Karara bağlamadan önce hızlı bir kontrol listesi

Bir çok kiracılı SaaS veri modelini kesinleştirmeden önce birkaç test çalıştırın. Amaç veri sızıntılarını erken yakalamak ve tablolar büyüdüğünde seçiminizin hâlâ işe yaradığını onaylamaktır.

Bir günde yapabileceğiniz hızlı kontroller

• Veri izolasyon kanıtı: iki kiracı (A ve B) oluşturun, benzer kayıtlar ekleyin ve her okuma/güncellemenin aktif kiracıyla sınırlı olduğunu doğrulayın. Sadece UI filtrelerine güvenmeyin.
• İzin kırılma testi: Tenant A kullanıcısı olarak oturum açın ve yalnızca kayıt ID'sini değiştirerek Tenant B kaydını açmayı, düzenlemeyi veya silmeyi deneyin. Başaran bir şey varsa, bunu bir sürüm engelleyicisi olarak ele alın.
• Yazma yolu güvenliği: yeni kayıtların background job'lar, içe aktarmalar veya otomasyonlar yoluyla bile doğru kiracı değerini aldığından emin olun (veya doğru şema/veritabanına yazıldığından).
• Raporlama denemesi: kiracıya özel bir rapor ve "tüm kiracılar" raporu (iç personel için) çalıştırabildiğinizi doğrulayın; kimlerin global görünümü görebileceğine dair net kurallar belirleyin.
• Performans kontrolü: şimdi bir indeks stratejisi ekleyin (özellikle (tenant_id, created_at) ve diğer yaygın filtreler için) ve en az bir yavaş sorguyu kasıtlı olarak çalıştırarak "kötü"nin nasıl göründüğünü görün.

Rapor testi için iki soru seçin (biri kiracı odaklı, diğeri global) ve bunları örnek veriye karşı çalıştırın.

-- Tenant-only: last 30 days, one tenant
SELECT count(*)
FROM tickets
WHERE tenant_id = :tenant_id
  AND created_at \u003e= now() - interval '30 days';

-- Global (admin): compare tenants
SELECT tenant_id, count(*)
FROM tickets
WHERE created_at \u003e= now() - interval '30 days'
GROUP BY tenant_id;

AppMaster'da prototipliyorsanız, bu kontrolleri Business Process akışlarınıza (okuma, yazma, silme) entegre edin ve Data Designer'da iki kiracı tohumlayın. Bu testler gerçekçi veri hacmiyle geçerse, seçimde daha emin olabilirsiniz.

Örnek senaryo: ilk müşterilerden ölçeklenmeye kadar

20 kişilik bir şirket müşteri portalı (faturalar, ticket'lar, basit pano) başlatıyor. İlk ay 10 kiracı, yıl içinde 1.000 kiracı hedefliyor.

Erken dönemde en basit model genellikle her müşteri verisini tutan tablolarda tenant_id bulunan tek veritabanıdır. Hızlı inşa edilir, raporlama kolaydır ve çoğaltılmış kurulumdan kaçınır.

10 kiracıdayken en büyük risk performans değil, izinlerdir. Bir filtreyi unutmak (ör. tenant_id'yi unutan "liste faturalar" sorgusu) veri sızıntısına neden olabilir. Ekip kiracı kontrollerini tek, tutarlı bir yerde zorunlu kılmalı (paylaşılan iş mantığı veya yeniden kullanılabilir API kalıpları) ve kiracı kapsamını tartışılmaz kural yapmalıdır.

10'dan 1.000'e geçerken ihtiyaçlar değişir. Raporlama ağırlaşır, destek "bu kiracı için her şeyi dışa aktar" ister ve birkaç büyük kiracı trafiği domine edip paylaşılan tabloları yavaşlatabilir.

Pratik bir yükseltme yolu genelde şöyle görünür:

1. Aynı uygulama mantığını ve izin kurallarını koruyun, ama yüksek hacimli kiracıları ayrı şemalara taşıyın.
2. En büyük veya uyumluluk gerektiren kiracıları ayrı veritabanlarına taşıyın.
3. Tüm kiracılardan okuyan paylaşılan bir raporlama katmanı tutun ve ağır raporları off-peak çalıştırın.

Bugün veriyi güvenli ayıran en basit modeli seçin; sonra "birkaç dev kiracı" problemini çözmek için geçiş yolu planlayın; ilk günden optimize etmeye çalışmayın.

Sonraki adımlar: bir model seçin ve no-code backend'te prototipleyin

Öncelikle neyi korumak istediğinize göre seçin: veri izolasyonu, operasyonel sadelik veya kiracı düzeyinde ölçeklenebilirlik. Güven, küçük bir prototip inşa edip gerçek izin ve raporlama durumlarıyla kırmayı denemekten gelir.

Basit başlangıç rehberi:

• Çoğu kiracı küçükse ve basit çapraz-kiracı raporlama gerekiyorsa, her satırda tenant_id bulunan tek bir veritabanıyla başlayın.
• Daha güçlü ayrım ama tek bir veritabanı yönetimi istiyorsanız, kiracı başına şemaları düşünün.
• Sert izolasyon gerekiyorsa (uyumluluk, ayrılmış yedekleme, gürültülü komşu riski), ayrı veritabanlarını değerlendirin.

Kurulumdan önce kiracı sınırlarını düz yazıyla belirleyin. Roller (owner, admin, agent, viewer), her rolün neler yapabileceği ve "global" verinin ne anlama geldiğini (planlar, şablonlar, denetim logları) tanımlayın. Raporlamanın nasıl işleyeceğine karar verin: sadece kiracıya özel mi, yoksa iç personel için "tüm kiracılar" görünümü mü olacak.

AppMaster kullanıyorsanız, bu desenleri hızlıca prototipleyebilirsiniz: Data Designer'da tabloları modelleyin ( tenant_id, benzersiz kısıtlar ve sorgularınızın dayanacağı indeksler dahil) ve Business Process Editor'de kuralları uygulayarak her okuma ve yazmanın kiracı kapsamlı kalmasını sağlayın. Referans olarak, AppMaster platformu appmaster.io.

Pratik son test: iki kiracı (A ve B) oluşturun, benzer kullanıcılar ve siparişler ekleyin ve her iki kiracı için aynı akışları çalıştırın. A için bir rapor dışa aktarın, sonra kasıtlı olarak B ID'lerini aynı uç noktalara geçirin. Prototipiniz ancak bu denemeler her seferinde başarısız olduğunda ve ana raporlar gerçekçi veri boyutlarında hâlâ hızlı çalıştığında "yeterince güvenli" sayılmalıdır.