⚠️ Arşiv Notu: Bu sayfa aktif akışın ana referansı değildir; geçmiş tasarım/bağlam için korunur.

Queue ve Worker Akışı

Cınga’da kritik karar, ingest hattını hafif tutup analitik hesapları asenkron worker’lara ayırmaktır. Bu sayede cihazdan veri kabulü gecikmez, sentez ve pencere yükü ayrı ölçeklenir.

Redis tarafında iki ana kuyruk kullanılır: synth_queue ve window_queue. Hata yönetimi için dead_letter_queue önerilir. Konuşmalarda özellikle netleştirdiğimiz konu, queue mesajının minimal tutulmasıdır: yalnızca stream_id ve device_id. Tam ham payload’ın queue’da taşınması bellek ve operasyon riski nedeniyle tercih edilmez.

Redis’te kuyruk mesajı JSON gövdesiyle saklanır (List ya da Stream yapısı fark etmeksizin gövde aynı kalabilir). Önerilen mesaj şeması:

{
  "stream_id": 9823412,
  "device_id": "96000000C49BB670",
  "created_at": "2026-03-11T10:28:30Z",
  "attempt": 0
}

DLQ’ya düşen mesajlarda aynı gövdeye hata bağlamı eklenir:

{
  "stream_id": 9823412,
  "device_id": "96000000C49BB670",
  "attempt": 5,
  "failed_at": "2026-03-11T10:29:10Z",
  "error_code": "SYNTH_CALC_FAIL",
  "error_message": "division by zero",
  "stage": "synth_worker"
}

İş akışı doğrusal ama dayanıklı kurgulanır. Ham segment yazımı bittikten sonra Redis kuyruğa yalnızca stream_id ve device_id bırakılır. synth_worker bu kaydı tüketir, DB’den ilgili ham segmentleri okur ve cihazın sentez kural setini (cihaz özel > global) çözüp hesaplarını üretir. Sentez çıktısının kalıcı tablo modeli bir sonraki aşamada netleşecektir. window_worker aşaması da sentez persist modeli netleşince sıradaki adım olarak ele alınacaktır.

Bu modelin güvenli çalışması için idempotent upsert, dedupe/lock, retry/backoff ve DLQ politikası zorunludur. Redis hız katmanıdır; doğruluk kaynağı daima DB kalır.