Engineering Case Study
Caflow
Multi-Tenant Restaurant Operations Platform
Restoran ve kafe operasyonlarında satış, sipariş, mutfak, stok, personel ve finans süreçlerini aynı platform altında modelleyen aktif bir SaaS ürün projesi.
Project Type
Active SaaS Product
Development Model
AI-Assisted Software Development
AI destekli geliştirme araçları; implementasyon hızlandırma, kod inceleme, hata ayıklama, keşif ve dokümantasyon süreçlerinde kullanılır. Mimari, ürün kapsamı, güvenlik sınırları, kabul kriterleri ve nihai doğrulama kararları mühendislik sürecinde insan tarafından yönlendirilir ve gözden geçirilir.
Tech Stack
Capability Status
Case study, çalışan ürün ile foundation veya geliştirme aşamasındaki alanları birbirinden ayırır; roadmap öğeleri tamamlanmış özellik gibi sunulmaz.
Engineering Challenges
Multi-Tenant Architecture & Tenant Isolation
Caflow'da tenant izolasyonu yalnız arayüz görünürlüğüne bırakılmaz. Authenticated server context; aktif işletme üyeliğini, yetkili işletmeyi, lokasyonu ve normalize rolü çözer. Domain kayıtları kapsamına göre business_id ve gerektiğindelocation_idile sınırlandırılır; RLS, grants ve kontrollü RPC'ler bu sınırı veritabanında savunma katmanlarıyla destekler.
Role-Based Authorization
owner, manager, cashier,waiter, accounting, personnelve operasyonel roller farklı yetki alanlarına sahiptir. Menü görünürlüğü kullanılabilirlik içindir; gerçek authorization server/service/RPC katmanında uygulanır ve bilinmeyen rol veya işlem fail-closed biçimde reddedilir.
Inventory Consistency
Ürün, reçete ve stok hareketleri ortak domain sözleşmeleriyle ilişkilidir. Stok etkileri satış ve üretim yaşam döngüsündeki kontrollü hareketlerle uygulanır; kritik write işlemlerinde idempotency, concurrency guard'ları, constraint'ler ve gerektiğinde reversal yaklaşımı kullanılır. Böylece stok motoru farklı satış kanalları için ayrı ayrı kopyalanmaz.
External Integrations & Credential Handling
Entegrasyon kimlik bilgileri düz metin olarak public yüzeylere taşınmaz. Desteklenen connector akışlarında credential'lar şifrelenmiş biçimde saklanır ve yalnız yetkili entegrasyon işlemlerinde çözülüp kullanılır. Sağlayıcıya özgü canlı bağlantı yetenekleri ise yalnız doğrulanmış adapter/connector seviyesinde tamamlanmış kabul edilir.
AI Authorization Boundaries
Business AI / Copilot tarafında model arbitrary SQL, tablo veya RPC seçemez. Doğal dil isteği kayıtlı tool kimliğine eşlenir; rol, tenant ve location context denetimlerinden sonra mevcut domain read modeline yönlendirilir. Yazma gerektiren AI destekli akışlar ise ayrı, kontrollü uygulama sınırları ve gerektiğinde kullanıcı onayı üzerinden ele alınır.
Architecture Overview
Authenticated Client (Web / PWA) │ ▼ Next.js Application (App Router / Server Actions) │ ▼ Authenticated Server Context │ user → membership → business → location → role ▼ Application / Service Boundaries ├── Sales & Fulfillment ├── Inventory & Recipes ├── Personnel & Payroll ├── Finance ├── Integrations └── Business AI │ ▼ PostgreSQL / Supabase └── RLS + grants + controlled RPC boundaries
Sanitized Engineering Examples
Aşağıdaki örnekler production kaynak kodunun birebir kopyası değildir; Caflow'un güvenlik yaklaşımını secret, gerçek tenant kimliği veya özel iş mantığı açığa çıkarmadan anlatan sadeleştirilmiş örneklerdir.
export async function resolveTenantContext() {
const user = await requireAuthenticatedUser();
const context = await getAuthorizedRuntimeContext(user.id);
if (!context.ok) throw new AccessDeniedError();
return {
businessId: context.businessId,
locationId: context.locationId,
role: context.role,
};
}const context = await resolveTenantContext();
const orders = await db.orders.findMany({
businessId: context.businessId,
locationId: context.locationId,
});
// Database RLS / grants provide an additional isolation layer.Daha fazlasını keşfedin
Gerçek müşteri verisine dokunmadan satış → mutfak → stok akışını sentetik sandbox içinde deneyebilirsiniz.