Dağıtık Pazaryeri İşleme Mimarisi

1. Sistem Profili ve Hedef Yığın

Mimari şartname v2.2.0; Java 25, PHP 8.2.12, MySQL 8.0 ve JavaScript tabanlı bir çalışma yığınını hedefler.

Baseline küme profili 13 aktif partner, partner başına 3 pazaryeri, toplam 39 hesap ve hesap başına ortalama 2.000 listing üzerinden tanımlanmıştır. Listing hacmi 20 ile 20.000 arasında değişebilir ve başlangıç kümesi 3 sunucudur.

2. Leader Election, Lease ve Split-Brain Koruması

Kümede herhangi bir anda en fazla bir aktif lider bulunması hedeflenir. Sunucular hibrit yetkinliktedir; gerektiğinde Worker veya Chief rolü üstlenebilir.

Liderlik kalıcı bir unvan değildir. Şartname 15 saniyelik lease ve 5 saniyelik leader heartbeat tanımlar. Yeni lider seçiminde monotonik fencing token artırılır; eski token ile gelen planlama veya yazma talepleri HTTP 409 ile reddedilmek üzere tasarlanır.

Failover eşiği 120 saniye olarak tanımlanmıştır. Bu mekanizma eski liderin uzun bir duraklamadan sonra yeniden yazma yaparak split-brain oluşturma riskini sınırlar.

3. Kapasite, Slot İzolasyonu ve Pazaryeri Kotası

Her sunucuda en fazla 3 aktif görev çalışacak şekilde bir slot modeli tanımlanır ve aynı sunucuda aynı pazaryerine ait birden fazla aktif iş çalıştırılmaması amaçlanır.

Küme kapasitesi aktif sunucu sayısı N için N × 3 formülüyle büyür. Üç sunucuda teorik eşzamanlı tavan 9 görevdir; dördüncü sunucunun eklenmesiyle kapasite 12’ye genişler.

Pazaryeri bazlı küme kotası, tek bir kanalın tüm cluster kapasitesini tüketmesini önlemek için aktif sunucu sayısıyla ilişkilendirilir.

4. Uzun Süreli Görevler ve Progressive Persistence

Büyük hesaplar tek bir uzun süreli crawl_task olarak Worker’a atanabilir. Görev saatler sürebilir ve sayfalar arasında stream yaklaşımıyla ilerler.

Şartname, tüm kayıtların bellekte tutulması yerine belirli aralıklarla PHP API katmanına aktarılmasını öngörür. Örnek batch boyutu 100 kayıttır.

Ancak atomic/idempotent progressive flush uygulaması production öncesi P0 çalışma olarak işaretlenmiştir. Bu nedenle bu mekanizma, doğrulanmadan production-ready yetkinlik olarak sunulmamalıdır.

5. Task Heartbeat, Checkpoint ve Resume

Uzun süren görevlerde Worker’ın her 20 saniyede bir task heartbeat göndermesi; server_id, fencing_token, current_page, last_cursor_token ve processed_count gibi alanların taşınması hedeflenir.

Checkpoint yaklaşımının temel kuralı ilerlemenin geriye gitmemesidir. processed_count, current_page ve total_discovered_count monotonik kalmalıdır. Eski bir heartbeat liveness sinyali olarak kabul edilse bile daha yeni ilerleme bilgisini overwrite etmemelidir.

Retry veya yeniden atama sonrasında görev, en son geçerli checkpoint bilgisinden devam edebilmelidir. Monotonic checkpoint update’in PHP heartbeat endpoint’inde tamamlanması production öncesi P0 kalemidir.

6. Size-Aware Fair Scheduling

20 ile 20.000 listing arasındaki büyük varyans, yalnız FIFO yaklaşımıyla yönetildiğinde küçük hesapların uzun süre beklemesine neden olabilir.

Aereo şartnamesi küçük işleri ve SLA gecikmesi yüksek hesapları dengeleyen, aging korumalı size-aware bir planlama yaklaşımı tanımlar. Bilinmeyen boyutlu yeni hesaplar için de cold-start keşif kuralları bulunur.

Amaç en büyük katalogların tüm slotları sürekli rehin almasını engellerken yeni ve küçük hesapların veri güncelliğini korumaktır.

7. Java 25 Runtime ve Eşzamanlılık

HTTP ve sayfalama ağırlıklı I/O operasyonlarında Java 25 virtual thread yaklaşımı hedeflenir. Bu model uzun süreli ağ işlemlerinde klasik thread maliyetini ve bellek baskısını azaltmayı amaçlar.

Java katmanının MySQL veritabanına doğrudan bağlanması yasaktır; koordinasyon ve kalıcı veri işlemleri PHP REST API katmanı üzerinden yürütülür.

8. Servis Güvenliği ve Veri Bütünlüğü

Task ownership ve fencing kontrolleri, eski Worker veya eski lider tarafından üretilen işlemlerin kabul edilmesini engellemek için kullanılır.

Servis çağrılarında HMAC-SHA256, timestamp ve nonce tabanlı doğrulama; replay ve payload/method/path tamper senaryolarına karşı koruma gereksinimleri tanımlanmıştır.

Trusted-origin politikası aynı scheme, host, effective port ve güvenilir path prefix sınırını öngörür. Production ortamında HTTPS zorunluluğu hedeflenir ve redirect otomatik takip edilmez.

Veri erişiminde prepared statements, transaction, FOR UPDATE / SKIP LOCKED ve unique guard gibi bütünlük mekanizmaları production mimarisinin parçasıdır.

9. Test Stratejisi ve Production Readiness Gate

Kapsam v2.2.0, CrawlTaskOrchestratorTest için 42 executable diagnostic/contract test bulunduğunu ve 42/42 sonucunun PASS olduğunu belirtir.

Bu testlerin bir bölümü deterministic contract simulation’dır. Doküman açıkça bu doğrulamaların gerçek PHP + MySQL transaction/concurrency integration testinin yerine geçmediğini belirtir.

Production readiness öncesinde initial election, failover sınırı, stale fencing, concurrent plan/acquire, heartbeat lease boundary, retry, checkpoint regression, reassignment, idempotent completion ve HMAC replay/tamper senaryolarının gerçek PHP endpoint’leri ve MySQL 8 üzerinde doğrulanması zorunlu gate olarak tanımlanmıştır.

10. Açık P0/P1 Çalışmaları

P0: PHP heartbeat endpoint’inde monotonic checkpoint update; 100 kayıtlık atomic/idempotent progressive product flush; gerçek PHP + MySQL concurrency/integration suite; production/test DB schema, index ve unique constraint doğrulaması.

P1 hardening: server-authoritative cluster policy ve Java parity validation, task completion single-flight/CAS, startup invariant validation, production profilinde insecure HTTP’nin kapatılması ve kimlik/marketplace yeteneklerinin gerektiğinde daha güçlü composite kontratlara taşınması.

P2 operasyonel kalite: CPU/RAM telemetry hattı, typed API exception sınıfları, history capacity konfigurasyonu ve nonce cleanup stratejisinin iyileştirilmesi.