Bir müşteri açık bir talep getirdi: Teramind'den gelen aktivite verisini istiyorlardı, ama şirket içinde kimsenin "hangi platform" sorusuna cevap bulmasını istemiyorlardı. Raporları kendi raporlama ekipleri, kendi veritabanları üzerinden hazırlayacaktı. Bizim işimiz veriyi taşımaktı — kaynağı değil.
Bu tek cümlelik talep aslında iki ayrı şeyi test ediyordu: Teramind'in API'si bunu teknik olarak destekleyecek kadar açık ve esnek miydi? Ve biz, standart bir kurulumun çok ötesinde, müşteriye özel bir mimari kurgulayabilecek miydik? İkisinin de cevabı evet oldu — ve bu yazı o sürecin kaydı.
Teramind tarafı: API'nin gücü
Teramind'in resmi arayüzü dışında, verinin tamamına programatik olarak erişebileceğiniz tam donanımlı bir REST API'si var — kullanıcı/cihaz bazlı aktivite kayıtları, ajan durumları, davranış politikaları, hepsi uç noktalar üzerinden. Bu, "dashboard'u kullan" ile sınırlı kalmayan bir platform demek: veriyi kendi altyapınıza, kendi şemanıza, kendi kurallarınızla taşıyabiliyorsunuz. Bu vakanın teknik olarak mümkün olmasının nedeni buydu — API zengin olmasaydı, "kaynağı gizle" talebini karşılamanın hiçbir yolu olmazdı.
kymcu tarafı: mühendislik esnekliği
API'nin var olması yetmez — onu doğru mimariyle kullanmak gerekir. Kurduğumuz sistem üç katmanlı çalışıyor:
- Çekme: Teramind API'sinden, kullanıcı/cihaz bazlı aktivite verisi düzenli aralıklarla (varsayılan 15 dakika) çekilir.
- Ara depolama: Veri önce kendi kontrolümüzdeki bir SQLite veritabanına yazılır — aylık anlık görüntü tabloları (
MMYY_user_all_data) halinde, tam geçmiş izlenebilirlikle. - Aktarım: SQLite'taki güncel veri, müşterinin kendi MSSQL sunucusuna UPSERT (MERGE) ile gönderilir — birincil anahtar
(kullanıcı, tarih, program)— hiçbir zamanTRUNCATEkullanılmaz, veri kaybı riski yoktur.
Müşteri tarafında görünen tek şey: düzenli aralıklarla güncellenen bir user_all_data tablosu. Kaynağın ne olduğuna dair hiçbir metadata, hiçbir sync-log tablosu, hiçbir iz müşterinin veritabanına yazılmaz — bu bilinçli bir mimari karar, "her şeyi logla" refleksinin burada bilinçli olarak kırılması gerekiyordu. Standart bir Teramind kurulumunun bir adım ötesi: platformu, müşterinin organizasyonel ihtiyacına göre yeniden şekillendirmek.
Bulunan gerçek bir veri kaybı riski
Sistemi olgunlaştırırken, canlıda ciddi bir bug bulduk: senkronizasyon sorgusu WHERE is_active = 1 filtresi kullanıyordu — yani işten ayrılan veya pasif duruma geçen kullanıcıların geçmiş verisi de senkronizasyondan sessizce düşüyordu. Denetim/raporlama amaçlı bir sistemde bu ciddi bir sorun: geçmiş kayıtların pasif bir kullanıcı yüzünden kaybolması kabul edilemezdi.
Filtreyi kaldırıp tüm kullanıcıları (aktif + pasif) işleme aldık. Sonuç: izlenen kullanıcı sayısı 573'ten 818'e çıktı — kaybolan 245 kullanıcının geçmiş verisi tekrar göründü ve korunmaya başladı.
Incremental sync: sabit pencere yerine checkpoint
İlk tasarımda senkronizasyon "son 30 gün" gibi sabit bir pencereyi her seferinde yeniden çekiyordu — API'ye gereksiz yük, gereksiz tekrar. Bunun yerine bir checkpoint mekanizmasına geçtik: sistem her çalıştığında sync_metadata tablosundaki son senkron zaman damgasını okur, sadece o andan sonrasını çeker. İlk kurulumda geriye dönük bir varsayılan pencere kullanılır, sonrasında sistem tamamen artımlı çalışır.
Doğrulama: API ile DB'yi karşılaştırma
Bir senkronizasyon sisteminin en riskli tarafı "sessizce veri kaybetmesi"dir — hata vermez, sadece eksik yazar. Bunu yakalamak için ayrı bir karşılaştırma aracı kurduk: belirli bir tarih aralığı için API'den gelen günlük kayıt sayılarıyla veritabanındaki kayıt sayılarını karşılaştırıp gün bazlı, renkli bir HTML rapor üretiyor. Fark varsa hemen görülüyor.
Çıkarımlar
- Bir platformun gücü, arayüzüyle sınırlı değildir. Teramind'in API'si, dashboard'un çok ötesinde bir esneklik sağladığı için bu proje mümkün oldu — iyi bir API, platformun kendisi kadar değerlidir.
- "Standart kurulum" her zaman yeterli değildir. Müşterinin gerçek ihtiyacı çoğu zaman "ürünü olduğu gibi kullan"ın ötesinde; bizim işimiz bu farkı kapatacak mühendisliği yapmak.
- "Kaynağı gizle" bir kısıt değil, bir tasarım ilkesi olarak ele alınmalı. Metadata/log tablolarını nereye yazacağınızı en baştan düşünmezseniz, sonradan "bunu müşteri DB'sinden temizle" demek çok daha zor bir iştir.
- Filtreler sessiz veri kaybının en sık nedenidir.
is_active = 1gibi masum görünen bir koşul, denetim amaçlı bir sistemde geçmiş kayıtları yok edebilir. - UPSERT, TRUNCATE+INSERT'ten güvenlidir. Özellikle aynı anda birden fazla senkronizasyonun çakışabileceği ortamlarda, hedef tabloyu asla toptan silmeyin.
Bu vaka bizim için iyi bir özet: doğru platform (Teramind, zengin bir API ile) + doğru mühendislik (ihtiyaca özel mimari) bir araya geldiğinde, "bu mümkün mü?" sorusunun cevabı neredeyse her zaman evet oluyor.