En Önemli Fark: SaaS Mimarisi (Tek Çatı Altında Yaşam)


Senin bahsettiğin standart scriptlerde (SmartPanel, Glycon vb. ***** veya bireysel lisanslı scriptler), her site farklı bir hostingde, farklı bir veritabanında barınır.
  • Standart: A sitesi B sitesine bağlanmak için internet üzerinden HTTP isteği (cURL) atar. Sonra durum sormak için yine istek atar. Bu yüzden Cron gerekir.
Perfect Panel'de ise durum şudur:
Perfect Panel bir SaaS (Software as a Service) yapısıdır. Yani o 5000 sitenin hepsi, aslında Perfect Panel'in devasa sunucu kümelerinde (Cluster) çalışır.
  • Perfect Panel: Panel A ve Panel B aslında aynı yazılımın içindeki iki farklı kiracıdır.
Bu ne anlama geliyor?
Panel A, Panel B'den API çektiğinde, sistem internete çıkıp dolaşmaz. Yazılım kendi içinde "Internal Routing" (İç Yönlendirme) yapar.

2. Cron Yok, \"Event-Driven\" (Olay Güdümlü) Yapı Var


Standart panellerde mantık şudur: "Git bak bakalım sipariş bitti mi?" (Polling - Sürekli sorma).
Perfect Panel'de mantık şudur: "Sipariş bittiğinde bana haber ver." (Push / Webhook / Event).
Senaryo: 10'lu Zincir (Panel 1 $to$ Panel 2 $to$ ... $to$ Panel 10)
Panel 10 (Ana Sağlayıcı) siparişi "Tamamlandı" olarak işaretlediğinde:
  1. Veritabanında Panel 10'un sipariş durumu değişir.
  2. Sistem, bu siparişin bağlı olduğu "Parent ID"yi (Üst Sipariş ID'sini) kontrol eder.
  3. Bunun Panel 9'dan geldiğini görür. Anında bir tetikleyici (Trigger) çalışır ve Panel 9'daki durumu günceller.
  4. Panel 9 güncellenince, onun tetikleyicisi Panel 8'i günceller.
Bu işlem veritabanı seviyesinde veya RAM tabanlı (Redis gibi) kuyruk sistemlerinde milisaniyeler içinde gerçekleşir. Cron'un "1 dakika bekleme" süresi burada yoktur. Domino taşları gibi anında düşerler.

3. Zincirleme Sipariş ve Bakiye Kontrolü (Balance Check)


Sorduğun kritik soru: "9. panelde bakiye bitmişse, sipariş bana (1. panele) nasıl ulaşacak veya hata verecek?"
Burada "Transactional" (Atomik İşlem) mantığı devreye girer. Hepsi aynı altyapıda olduğu için süreç şöyle işler:
  1. Sen (Panel 1) siparişi girdin.
  2. İstek Panel 2'ye gider. Panel 2'nin bakiyesi var mı? Evet. $to$ Panel 3'e ilet.
  3. ...
  4. İstek Panel 9'a geldi. Panel 9'un Panel 10'da bakiyesi var mı? Hayır.
  5. Sistem zincirin en ucunda (veya koptuğu yerde) hatayı yakalar.
  6. Hata kodu geriye doğru (Panel 9 $to$ 8 $to$ ... $to$ 1) anında döner.
  7. Senin panelinde sipariş "Fail" veya "Canceled" düşer ve bakiyen otomatik iade edilir.
Bu işlem siparişi "Processing"de bekletip sonra kontrol etmekle değil, sipariş oluşturulma anında (Instant API response) gerçekleşir. Eğer API ile bağlıysa ve bakiye yetersizse, Perfect Panel API'si direkt {error: "Not enough funds"} döndürür ve zincir orada kopar, sipariş hiç oluşmaz.

4. Global ID ve Eşleştirme Nasıl Yapılıyor?


"Global ID" dediğimiz şey aslında bir Mapping Table (Eşleştirme Tablosu) dur.
Normalde sen kendi veritabanında Sipariş ID: 50 tutarsın, karşı tarafta bu Sipariş ID: 5000 olur.
Perfect Panel merkezi bir yapı olduğu için arka planda şöyle bir tablo tutar:
Master_Order_ID (Global)Panel_IDLocal_Order_IDParent_Order_IDStatusUUID-XYZ-123

Panel 10

99999

NULL (Ana Kaynak)

Completed

UUID-XYZ-123


Panel 9

500

99999 (Panel 10)

Completed

UUID-XYZ-123

Panel 8

20

500 (Panel 9)

Completed

Sistem bir güncelleme yapacağı zaman Local_Order_ID ile uğraşmaz. O arkadaki Master ID (veya Linkage ID) üzerinden o zincire bağlı tüm siparişleri bulur ve hepsinin statüsünü tek bir komutla günceller.

Özetle Mantık Nedir?

  1. Aynı Evin Odaları: Perfect Panel kullanan siteler, farklı siteler gibi görünse de aynı yazılımın farklı odalarıdır. Birbirleriyle konuşmak için telefona (internet/API) ihtiyaç duymazlar, kapıdan seslenmeleri (iç triggerlar) yeterlidir.
  2. Webhook / Socket: Cron gibi "acaba bitti mi?" diye zamanlanmış görevler yerine, "bitti, güncelle" diyen anlık bildirim sistemleri kullanırlar.
  3. Merkezi Veritabanı İlişkisi: Bir siparişin 10 farklı paneldeki kaydı, arka planda birbirine "Linked List" (Bağlı Liste) mantığıyla bağlıdır. Biri değişince zincirdeki diğer halka otomatik tetiklenir.
Senin o arada "30 saniye, 1 dakika" gecikme yaşamamanın sebebi, bu sitelerin birbirine HTTP isteği atmaması, veritabanı veya önbellek (Redis) üzerinde doğrudan haberleşmesidir.