Burada Database Kayıt Sistemi Nasıl Çalışıyor Olabilir?

Selamlar,

Bu konuyu daha önce de açmıştım lakin tam bir cevap alamadığım için tekrardan sormak istiyorum.
Şimdi,Perfect Panel - Smm Panel scripti adında bir script var bu scriptde 5000 adet site var(örneğin) ve bu 5000 site kendi içinde tam senkronize çalışmakta.
Hepsi aynı databaseyi kullanıyor diye biliyorum.
Sorumuz nedir?

Normalde farklı paneller olsa cron sistemiyle sipariş atılır,1 dakika aralıklarla siparişin durumu get edilir. Ve eğer sipariş completed olduysa 1. panelin önce cronu algılar,sonra 2. panel filan bu şekilde de zaman aşımı olur.(Yani ana panel 30 saniyede tamamlandıysa,3. panele geçmesi 1 dakika da sürebilir,3 dakikada.)
Perfect Panel Ne Yapıyor?
10 farklı site birbirimizden api çekiyor olalım.
Ana panel benim sitem olsun.Ara panellerden 9. panel benden alıyor,8. panelde 9'dan alıyor.
Ben 10. panelde(ana site bizim olsun) işlem yaptığımda hem 9 hem de 8. panel anında yansıyor.
Yani 10. panelde işlem yaptığımda diğer o arkasındaki 8-9 sitede anında etkileniyor ve işlemler zaman aşmadan yapılıyor.

Önceki konumda "Global_id" değişkeni veriliyordur ve o şekilde sipariş iletiliyordur denildi.
Örneğin 9. panelde api bakiyesi bitmişse,sipariş processingde kalacak o siparişi bana ulaşıp ulaşmamasını nasıl ayarlayacak?
Veya 1. siteden sipariş girdiğimde 9 panelden geçecek,o global_id'nin aynı sipariş olduğunu nasıl biliyoruz yani tamam 8'den 9'a siparişi atalım ama aynı global_id olduğuna nereden eminiz?
Burada mantık tam olarak ne oluyor?

Pek anlatamamış olabilirim,dilimin döndüğü kadarıyla anlatmaya çalıştım.

Hocam sanırım hepsi için farklı veritabanı oluşturuluyor aynı hostingdeki gibi.
kullanıcıadi_siteismi gibi

Öyle de olabilir,ama örneğin bu mantıkla bakacak olursak 10 tane sitede api çektiğimizi varsayarsak her işlemde 10 tane sql sorgusu oldukça sistem için mantıksız.Çünkü perfect panel günlük milyonlarca sipariş aktarması gerekiyor ve her işlem için inprogress'e al,start count al gibi gibi türlü işlemler yapıyoruz ve her işlem için 10x sorgu oldukça mantıksız olacak.(10x derken buradaki örnekte 10 panel dediğim için.)

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.

Ns yönlendirmesi yapılıyor ilgili firmaya, hosting hizmeti gibi düşünebilirsiniz hosting ücreti de içinde oluyor fiyatın yani herkesin sitesi aynı database içinde yer almamıyor

Hocam tamam orasını anladım lakin 10 farklı perfect panel hepsinde aynı anda completed olmasının mantığı ne olabilir?
Hepsi nasıl aynı anda completed oluyor?
Hepsi farklı databasede ise örneğin 1 sipariş için öncelikle inprogress'e alırız,sonra start count gireriz,sonrasında completed yaparız. 10 panelde bu işlemler yapılması gerekse 3 sorgu 1 panelde yapılıyor,ve bunlar aynı anda yapılmıyor 10 saniye aralıklarla filan yapılıyor 10 farklı panel için 30 adet sorgu demek. Ki bu sadece 1 sipariş için. Perfect Panel bir günde 100 Milyon civarı veya fazlası sipariş yapıyor ve her biri için bu kadar sorgu yapacağını düşünürsek çıkan sonuç oldukça mantıksız değil mi?

Tekrar selamlar, çok doğru bir yerden yakaladın. Zaten standart bir yazılımcının "bu kadar yükü nasıl kaldırıyorlar?" diye kafayı yaktığı nokta tam olarak burasıdır.
Senin yaptığın hesapta "Lineer (Doğrusal) İşlem" mantığı var. Yani:
"Önce A'yı güncelle, bitti. Sonra B'yi güncelle, bitti. Sonra C..."
Eğer Perfect Panel (veya benzeri dev yapılar) bu mantıkla çalışsaydı, dediğin gibi sistem 1 saat içinde kilitlenirdi.
Buradaki sihirli kelimeler şunlar: Tek Veritabanı Mimarisi (Single Tenant DB), Indexing ve Cache (Önbellek).
Gel senin "10 farklı panel, 10 farklı sorgu" tezini çürüterek sistemin nasıl tek bir parmak şıklatmasıyla 10 paneli güncellediğini anlatayım.

1. \"Farklı Database\" Yanılgısı

En büyük yanılgı burada. Perfect Panel'deki o 5000 sitenin hepsi (çok çok yüksek ihtimalle) fiziksel olarak aynı veritabanı sunucusunda (veya cluster'ında), aynı tablonun içindedir.
Düşün ki orders diye devasa bir tablo var. Milyarlarca satır var.
Tablo yapısı şuna benzer:
idpanel_idservice_idstatusupstream_order_idroot_order_id100Panel_10 (Ana)5CompletedNULLGUID-123101Panel_920Completed100GUID-123102Panel_855Completed101GUID-123..................110Panel_1 (Sen)99Completed109GUID-123Gördüğün gibi hepsi aynı tabloda.
Şimdi ana sağlayıcı (Panel 10), "Sipariş Tamamlandı" dediğinde sistem arka planda 10 tane ayrı sorgu atmaz.
Şöyle tek bir SQL sorgusu çalıştırır:
SQLUPDATE orders SET status = 'completed' WHERE root_order_id = 'GUID-123';
Bum! Tek bir satır kod. Veritabanı motoru (PostgreSQL veya MySQL), root_order_id üzerinde "Index" olduğu için bu işlemi milisaniyeler içinde yapar. İsterse o zincirde 100 tane panel olsun, veritabanı için bu "tek bir işlemdir".
Yani senin düşündüğün gibi "Önce 9'a git, sonra 8'e git" diye bir döngü yok. Toplu güncelleme (Bulk Update) var.

2. \"Read-Through\" (Okurken Çekme) Tekniği

İkinci bir ihtimal (ve daha modern bir yaklaşım) ise veritabanını bile yormamaktır.
Sen Panel 1'in sahibi olarak "Siparişler" sayfasına girdiğinde, sistem senin veritabanı satırındaki "status" sütununa bakmak yerine, Cache (Redis) katmanına bakar.
Sistem şöyle çalışır:

1. Ana sağlayıcı siparişi tamamlar.
2. Redis'e (RAM belleğe) şu bilgi girilir: Key: STATUS_GUID_123, Value: COMPLETED.
3. Sen, Ahmet, Mehmet veya zincirdeki diğer 9 panel sahibi sipariş sayfasına girdiğinde, ekranda gördüğü veri kendi veritabanından değil, o ortak Redis anahtarından okunur.

Bu sayede veritabanına UPDATE sorgusu atılmasına bile gerek kalmaz (veya bu işlem gece herkes uyurken topluca yapılır - Eventual Consistency). Sen ekranda "Completed" yazısını anında görürsün çünkü hepiniz aynı "RAM" bölgesine bakıyorsunuzdur.

3. Socket / Push Mimarisi (Görsel Hız)

Kullanıcı tarafında "Anında değişti" hissini yaratan şey WebSocket teknolojisidir.

1. Ana siparişin durumu değişir.
2. Sunucu, o siparişe abone olan (o zincirdeki) tüm tarayıcılara açık olan soket kanalına bir sinyal gönderir.
3. Senin ekranın yenilenmeden (F5 atmadan) statü "Processing"den "Completed"a döner.

4. Neden Standart Scriptlerde Bu Yok?

Senin kullandığın veya piyasadaki standart scriptlerde (SmartPanel vb.) her panelin veritabanı izoledir.

• Panel A'nın veritabanı Sunucu A'da.
• Panel B'nin veritabanı Sunucu B'de.

Bu durumda "Tek SQL ile hepsini güncelle" (Madde 1) yapamazsın. Mecburen API ile tek tek haberleşmek zorundasın. Cron gecikmesi işte buradan doğar.

Özetle Mantık Hatası Nerede?

Senin mantığındaki hata şu: "Her panelin kendi bağımsız veritabanı ve işlem sırası olduğunu" varsayıyorsun.
Perfect Panel'in gerçeği: "Herkes aynı havuzda yüzüyor, sadece birbirlerini görmüyorlar (Multi-tenancy)."
Havuzun suyu ısındığında (Sipariş tamamlandığında), herkes aynı anda ısınır. Tek tek ısıtmak gerekmez.

Siz tek tek mi siparişleri işleme alıyorsunuz hocam?
Multi olarak işleme alabiliyorsunuz glycon, perfect vb. Panellerde API dokümanlarına bakabilirsiniz yani aynı anda 100 siparişi tek istekle statusunu güncelleyebilirsiniz.

Glycon varsa sizde veya tanıdık birinde eğer proje dosyalarına bakın anlarsınız mantığı