Forchetto — Restoran Zincirleri için Yönetim Platformu
Masa, menü, sipariş ve mutfak akışını tek çatıda toplayan; Avrupa pazarına hazırladığımız multi-tenant restoran SaaS.
- Rol
- Kendi ürünümüz · Ürün & Mühendislik
- Stack
- Next.js · TypeScript · AWS Lambda · Aurora PostgreSQL · Cognito · SST
Parçalı araçların yorduğu bir sektör
Avrupa'daki bağımsız restoranlar ve küçük zincirler günlük operasyonu beş-altı farklı aracı yan yana koyarak yönetiyor: POS bir markadan, menü yönetimi başka bir SaaS'ten, mutfak ekranı bambaşka bir cihazdan, raporlar Excel'den. Her araç ayrı satın alınıyor, veri bir diğerine geçmiyor, fiyatlandırma özellik başına ekleniyor. Tek bir restoran için bu kurgu zaten pahalı; bir marka iki-üç şubeye ulaştığında tamamen tıkanıyor.
Forchetto'yu bu boşluğu kapatmak için başlattık. Masa planından menü yönetimine, garsonun sipariş alışından mutfaktaki akışa kadar bir restoran gününün operasyonel omurgasını tek bir platforma taşıyoruz. Hedef pazarımız Avrupa — birden fazla ülkedeki pilot restoranlarla canlıya almayı planlıyoruz.
“Multi-tenancy ve güvenliği sonradan değil, ilk commit'ten itibaren mimariye yerleştirmek.”
Yaklaşımımız
Forchetto'yu bir müşteriye özel bir uygulama olarak değil, baştan satılabilir bir SaaS olarak tasarladık. Bu, kurguyu baştan değiştiriyor: tenant izolasyonu, altyapı maliyeti, çoklu ortam yönetimi ve kimlik doğrulama gibi konuların MVP sonrasına ertelenmesi mümkün değildi — ilk mimari kararlarla birlikte masadaydılar.
Ürünü iki paralel katmanda geliştirdik: AWS-native serverless bir backend (Lambda, Aurora PostgreSQL, Cognito, SST ile infrastructure-as-code) ve mock veri üzerinde ilerleyen bir Next.js frontend. Frontend MVP tamamlandıktan sonra bu iki katmanı birbirine bağlamaya başladık; şu an entegrasyon aşamasındayız.
Teknik Kararlar
Row-Level Security ile tenant izolasyonu
Multi-tenant bir SaaS'te en yaygın iki yaklaşım, tenant başına ayrı veritabanı veya ayrı şema açmaktır. Biz üçüncü yolu seçtik: tek şema, tek tablo seti ve PostgreSQL'in Row-Level Security özelliği ile satır düzeyinde izolasyon. Her tablo tenant_id taşıyor, her sorgu Postgres session'ındaki tenant kimliğine göre otomatik filtreleniyor. Bu sayede "yanlış restoran yanlış veriyi göremez" garantisi uygulama katmanında unutabileceğimiz bir if-else'e değil, veritabanının kendi erişim denetimine bağlı. Yeni bir restoran onboard etmek ne yeni şema açılmasını ne de yeni veritabanı provisioned edilmesini gerektiriyor; bir satır eklemek yetiyor.
AWS serverless stack: Lambda + Aurora Serverless v2 + RDS Proxy
Erken aşama bir SaaS'in trafiği hem öngörülemez hem de zamanla kayıp sıçramalarla büyür. Sürekli çalışan bir backend sunucusu bu profile uyumsuz. Lambda'yı API katmanı, Aurora Serverless v2'yi otomatik ölçeklenen veritabanı olarak seçtik — düşük yükte neredeyse maliyet üretmeyen, zirve saatlerde kendiliğinden ölçeklenen bir profil. Serverless Postgres'in klasik bağlantı havuzlama sorununu RDS Proxy ile çözdük: Lambda'nın her çağrıda yeni bağlantı açması yerine Proxy üzerindeki havuzlanmış bağlantıları kullanıyoruz. Bu, Aurora'yı tüketmeden binlerce eşzamanlı Lambda çağrısına izin veriyor.
Cognito + merkezileşmiş AuthGuard
Kimlik doğrulamayı Amazon Cognito'ya devrettik; token yönetimi, parola politikaları, MFA ve forgot-password akışlarını sıfırdan yazmak bir tasarruf değil, risk ve bakım yüküdür. Frontend tarafında auth kontrolünü sayfa sayfa dağıtmak yerine tek bir AuthGuard katmanında topladık: giriş yapılmamış kullanıcı için redirect, rol kontrolü ve tenant doğrulaması bu tek noktada yürüyor. Yeni bir sayfa eklerken auth akışını yeniden kurmak gerekmiyor; AuthGuard altındaki tree'ye yerleştirmek yetiyor.
Tüm altyapının SST ile kod olarak tanımlanması
Lambda fonksiyonları, VPC yapılandırması, Aurora cluster, RDS Proxy, Cognito user pool, CloudFront dağıtımı — hepsi SST ile TypeScript olarak tanımlı. Dev, staging ve production ortamlarının her biri tek bir komutla ayağa kalkıyor ve birbirinin aynısı. Çoklu ortam yönetimini AWS konsolundan manuel tıklamalarla değil, PR'da gözden geçirilebilen kodla yapmak; bir ortamda çalışan bir şeyin diğerinde neden çalışmadığını diff ile görebilmek, erken aşama bir SaaS için beklediğimizden değerli bir disiplin oldu.
Arayüzden
Durum & Sonuç
Forchetto'nun frontend MVP'si mock veri üzerinde tamamlandı: masa yönetiminden menü editörüne, garson sipariş akışından mutfak ekranına ve QR menü görüntülemesine kadar hedeflediğimiz operasyonel akışların hepsi UI olarak çalışıyor. Backend tarafında da aynı akışları karşılayan Lambda uç noktaları, RLS politikaları ve Cognito yapılandırması hazır.
Şu an backend ile frontend arasındaki entegrasyonu bitiriyoruz. Bir sonraki adım, Avrupa'da pilot restoranlarla gerçek saha verisi üzerinde ürünü test etmek. Multi-tenant mimariyi, serverless maliyet profilini ve güvenlik katmanını sonradan eklemek yerine ilk sürümden itibaren yerleştirmiş olmak, bu geçişi bir refactor projesi değil, bir açılış süreci olarak yürütmemize izin veriyor.
SaaS olarak kurgulanacak bir ürün fikriniz mi var?
Kendi SaaS'inizi sıfırdan inşa etmeyi, mevcut bir ürünü multi-tenant mimariye taşımayı ya da AWS serverless altyapı kurmayı düşünüyorsanız konuşalım.
Teklif Alın