Çok Dilli Store’larda Lag Gözlemi (Cok Dilli Storelarda Lag Gozlemi)

Çok Dilli Store’larda Lag Gözlemi

Lag’i gizleyen harita güven kırar. Operators must see when Mongo is fresh but PostGIS is stale — lag is a product feature, not only a metric.

ERP ts → ETL ts → API ts → UI banner

Lag’i gizleyen harita güven kırar.

Kavramlar ilk geçtiği yerde

📦 Operational Store
ERP’nin yazdığı MySQL — günlük işlem için doğru, analitik için kirli.

📦 Analytics Store
Temizlenmiş PostgreSQL/PostGIS — coğrafi sorgu ve rapor için.

📦 Telemetry Store
Yüksek frekanslı konum olayları için belge/store (MongoDB).

📦 Search Index
Çok varlıklı ops araması için Elasticsearch kümesi.

Bu katmanları karıştırmak, hem analitikte hem frontend haritada yanlış gerçeğe yol açar.

Problemin şekli

Operators must see when Mongo is fresh but PostGIS is stale — lag is a product feature, not only a metric.

ERP ts → ETL ts → API ts → UI banner

Çalışan ayrım

Lag’i gizleyen harita güven kırar.

ERP ts → ETL ts → API ts → UI banner
        ↓
   explicit contract → frontend

Frontend ile bağ

Ops haritası, bekleme geofence UI’si ve MFE’ler bu okuma modellerini tüketir; ham ERP/MySQL’e bağlanmaz.

Bu bölümde en çok karışan eşleştirmeler

❌ ERP MySQL = analitik veritabanı
✓ ERP yazma store’udur; analitik PostGIS’te yaşar

❌ Harita doğrudan vendor/public router’a güvensin
✓ Üretimde kendi API/OSRM kenarınız olmalı

❌ ML çıktısı PII ile birlikte loglansın
✓ Değerlendirme ve serving gizlilik sınırına uyar

Kendi sisteminizi denetleme listesi

1. Bu yüzey hangi store’u source of truth sayıyor?
2. Frontend hangi API kontratını çağırıyor?
3. Cluster’da tek node kaybında ne olur?
4. Lag operatöre nasıl gösteriliyor?
5. Deny-list: içerikte müşteri domain/vendor sızıntısı var mı?

Bu bölümden aklında kalması gerekenler

1. Polyglot store’lar farklı iş yükleri içindir; tek DB hayali kırılgandır.
2. Frontend temiz read model tüketir, ERP’yi değil.
3. ML ve OSRM çıktıları API kontratı olmadan haritaya dökülmez.

Kirli kaynaktan çizilen harita, güzel bir yalandır.