Bildirim mimarisi: Gerçek zamanlı uyarılar ve kişiselleştirme

This article will walk you through how to setup, scale and customize real time notifications. The language is simple. All terms are briefly described when first encountered. The objective is to deliver technical correctness as well as practical utility.

İçindekiler

• Bildirim mimarisinin temelleri
• Gerçek zamanlı uyarılar nasıl çalışır?
• Kanala göre gönderim stratejileri
• Kişiselleştirme katmanı
• Teslim edilebilirlik, kalite ve deney
• Güvenlik, gizlilik ve mevzuat
• Referans mimari: uçtan uca tasarım
• Vaka: iGaming’de yüksek hacimli bildirimler
• Uygulama ipuçları ve sık hatalar
• SSS
• Sonuç ve sonraki adımlar

Bildirim mimarisinin temelleri

Sağlayıcı: Medium Turkce: Bildirim mimarisi, bir olay olduğunda doğru kullanıcıya, doğru kanaldan, doğru anda bilgi gönderen sistemdir. Ana fikir, olay güdümlü (event‑driven) çalışmaktır. Yani bir tetik (örneğin “sepet bırakıldı”) gelir, sistem bu tetik için kuralı bulur, metni hazırlar ve gönderir.

Ana bileşenler

• Olay kaynakları: Uygulama, veritabanı, analitik, fraud sistemi. Olayları bir akışa yazar. Sık kullanılan araçlar: Apache Kafka, Apache Pulsar, Redis Streams, Pub/Sub, SNS.
• Kuyruk ve sıralama: Olaylar biriktirilir, sıraya konur. Geri basınç (backpressure) ve yeniden deneme bu katmanda olur. Örnek: SQS.
• İşleyiciler (processors): Olayı alır, kullanıcıyı ve şablonu seçer, kuralları uygular.
• Şablon motoru: Mesaj metnini hazırlar. Kişiye göre alanları doldurur.
• Gönderim katmanı: Kanal adaptörleri. Örnek: FCM (Android), APNs (iOS), Web Push, e‑posta (ör. SendGrid), SMS.
• Tercih merkezi: Kullanıcı izinleri, kanal seçimi, sessiz saatler. KVKK ve GDPR uyumunun kalbidir.
• Geri besleme ve veri ambarı: Teslim, açılma, tıklama, iptal (unsubscribe) olayları geri gelir ve rapora gider.

Olay güdümlü vs istek/yanıt; Push vs pull

• Olay güdümlü: Olay olur, sistem tetiklenir. Ölçeklenir. Gecikme düşüktür.
• İstek/yanıt: Kullanıcı ister, sistem yanıtlar. Bildirim için zayıf olur.
• Push: Sunucu mesajı iter. Mobil/web push, e‑posta, SMS böyledir.
• Pull: İstemci arada bir yoklar. WebSocket ve SSE ile anlık akış sağlanır.

Gerçek zamanlı uyarılar nasıl çalışır?

When I say real-time, that means the time between event and notif delivery is short. You should aim to keep p95 latency (95% of notifs) under your target threshold. I find p95 = 2–5 seconds is good enough for most products. For alerts targeting emergencies, you should aim for p95 = 1 second.

Gecikme bütçesi (latency budget)

• Olay yazımı: 50–100 ms
• Kuyruk ve yönlendirme: 50–200 ms
• İşleme ve şablon: 50–150 ms
• Gönderim sağlayıcısı: 100–1000 ms (sağlayıcıya göre değişir)

Measure. You can't manage this budget without measurements. Recommendation: Monitoring with OpenTelemetry, metrics with Prometheus, graphing with Grafana.

Ölçeklenebilirlik ve dayanıklılık

• Yatay ölçek: İşleyici pods sayısını artırın. Otomatik ölçekleme kurun.
• Backpressure: Kuyruk uzunluğu ve işleme hızı dengelensin.
• Retry ve DLQ: Hata olursa artan bekleme (exponential backoff) ile yeniden deneyin. Olmazsa “dead letter queue”ya atın. Referans.
• İdempotency: Aynı olayı iki kez işlerseniz de sonuç bir kez olsun. İyi açıklama.
• Deduplikasyon: Çift mesajı önleyin. Kullanıcıyı yormayın.

Kanala göre gönderim stratejileri

Mobil ve web push

• Android: FCM. Konu (topic), cihaz grubu, token yönetimi.
• iOS: APNs. Sessiz bildirim (silent), içerik zengin bildirim.
• Web Push: W3C Push API ve MDN. Kullanıcı izni zorunlu.

Diğer kanallar

• In‑app: Uygulama içi banner, modal. Anında ve sessiz.
• E‑posta: Onay, parola, özet. Teslim için SPF/DKIM/DMARC gerekir. Google yönergeleri, Postmaster Tools.
• SMS: Az ve öz kullanın. Zamanlama hassas. Yerel kurallara uyun.
• Webhook: Partner sistemine anında bildirim. Örnek rehber.

Orchestration: Honor the user’s preferred channel. If unreachable, cascade to a fallback channel. Write a channel priority rule (e.g., push → in-app → email).

Kişiselleştirme katmanı

Personalization is serving the right content to the right person. The goal is to reduce noise and increase value.

Segmentasyon ve tetikleyiciler

• Segment: Ortak özelliği olan grup (ör. “ilk kez alışveriş yapmayanlar”).
• Tetik: Olay bazlı kural (ör. “sepet 30 dk dolu kaldı”).
• Özellik deposu (feature store): Kullanıcı özelliklerini hızlıca okur. Ör. “son alışveriş tarihi”, “ülke”.

Kural tabanlı vs ML tabanlı öneri

• Kural tabanlı: Basit, şeffaf, hızlı. Küçük ekipler için iyi başlangıç.
• ML tabanlı: Daha akıllı. İçerik ve zaman önerir. Küçük adımlarla başlayın. İlk olarak gönderim zamanı optimizasyonu yapın. “Çok kollu haydut” (multi‑armed bandit) ile başlık denemeleri yapılabilir.

Frekans sınırı ve sessiz saatler

• Frequency capping: Günlük/haftalık üst sınır koyun (ör. günde 2 push, haftada 5 e‑posta).
• Quiet hours: Gece saatlerinde rahatsız etmeyin. Yerel saate göre ayarlayın.
• Tercih merkezi: Kullanıcı tek tıkla kanalı kapatabilsin. KVKK için şarttır.

Teslim edilebilirlik, kalite ve deney

Metrikler

• Teslim oranı: Gönderilenlerin kaçı ulaştı.
• Açılma ve tıklama: İlgi ölçer.
• Gecikme p50/p95/p99: Hız ölçer. p95 en kritik.
• Abonelikten çıkış: Yorgunluk göstergesi.
• Hata oranı: Sağlayıcı ve ağ sorunlarını izler.

A/B testleri ve yorumlama

• Tek değişken test edin (başlık, zaman, kanal).
• Yeterli örneklem toplayın. Yanılma payını not edin.
• Yanlış pozitiften kaçın. “Kazananı” çok hızlı ilan etmeyin.
• Deney araçları için: Braze A/B, Airship Experiments.

Güvenlik, gizlilik ve mevzuat

Notifications are useless without user trust. Permission, privacy, and transparency are key.

KVKK/GDPR uyumu

• Açık rıza: Rıza net ve özgür olmalı. KVKK, EDPB.
• Çift onay (double opt‑in): E‑posta için iyi pratik.
• Abonelikten çıkış: Her mesajda kolay yol verin.
• Tercih yönetimi: IAB TCF uyumlu rıza akışı önerilir. TCF.

Güvenlik ve kayıt

• İdempotency ve deduplikasyon: Tekrarlı işlem ve spam riskini azaltır.
• Loglama ve denetim izi: Kim, ne zaman, hangi veriyi kullandı, izlenebilir olmalı.
• Ortak güvenlik ilkeleri: OWASP Top 10 risklerini kontrol edin.

Referans mimari: uçtan uca tasarım

This reference is simple and will scale for most teams.

• API Gateway: Uygulama olayları buraya gelir. İzin ve hız sınırı (rate limiting) uygulanır.
• Olay otobüsü: Kafka/Pulsar akışı. Konu bazlı ayrım (ör. “order”, “fraud”, “engagement”).
• İşleyiciler: Kural motoru, kullanıcı seçimi, şablon oluşturma. Stateless tasarım ölçek için iyidir.
• Şablon motoru: Çok dil, çok bölge desteği. Değişkenler ve koşullar.
• Gönderim adaptörleri: FCM, APNs, Web Push, e‑posta, SMS. Sağlayıcı yanıtlarını yakalayın.
• Geri besleme döngüsü: Teslim/açılma olayları tekrar akışa düşer. Model ve kural günceller.
• Gözlemlenebilirlik: İzleme, metrik, alarm. p95 gecikme kırmızı çizgi olsun.
• Hata yönetimi: Retry, exponential backoff, DLQ, manuel yeniden oynatma.

Basit veri akışı

Event → Tail → Processor → Template → Channel adapter → Provider → Acknowledge → Report.

Useful resources for the schema: Kafka doc, Apple UserNotifications, Firebase Docs.

Vaka: iGaming’de yüksek hacimli gerçek zamanlı bildirimler

iGaming is fast and live. There are frequent game, tournament, bonus, security and limits notifications. Pace and adaption are needed at the same time.

Ne tür uyarılar?

• Turnuva başlıyor veya skor güncellemesi
• Bonus zamanı, ancak kullanıcı rızası varsa
• Harcamada öz denetim ve limit hatırlatma
• Dolandırıcılık şüphesi, giriş uyarısı, cihaz değişimi

Özel gereksinimler

• Sorumlu oyun: 18+ ve yardım linkleri görünür olmalı. Bkz. BeGambleAware.
• Yaş ve bölge kontrolü: Yerel kurallar ve lisanslar farklıdır.
• Opt‑in ve tercih: Pazarlama mesajı için açık izin şarttır.

Users are encouraged to do their own research when using such reviews to find regulated, reputable operators. For an unbiased review, please refer to this link: site. This is for information purposes only, not an inducement or encouragement. Please gamble responsibly. 18+. Always show regional disclaimers.

Uygulama ipuçları ve sık hatalar

• Tek kanal bağımlılığı: Sadece push veya sadece e‑posta kullanmayın. Yedek kanal koyun.
• Tercih merkezini atlamak: İzin ve sessiz saat olmadan gönderim, hızla iptal ve şikâyet doğurur.
• Aşırı frekans: Kısa vadede tık artabilir, uzun vadede güven kaybı olur.
• Test eksikliği: Uçtan uca test ve yük testi yapın. Her kampanya için dry‑run planlayın.
• Gözlemlenebilirlik yokluğu: p95 gecikme, teslim oranı ve hata oranı için alarm kurun.
• İdempotency/dedupe eksikliği: Kullanıcıya iki kez aynı mesaj gitmesin.
• Şablon karmaşıklığı: Her kuralı şablona yığmayın. İşleyiciye mantık koyun.

SSS

Gerçek zamanlı bildirim için minimum mimari nedir?

One event source + simple queue + single processor + single channel adapter is all that's needed. Metrics and preference center should be added from the start.

FCM ve APNs farkı nedir?

FCM is for Android, easy to broadcast with Topic and Device Group. APNs is for iOS, great to support silent notification and rich content. Token management and Feedback are mandatory for both of them.

Web Push izni nasıl çalışır?

The browser asks for permission. If the user accepts the subscription is successful. To learn the specification check W3C and MDN.

KVKK kapsamında rıza ve çıkış nasıl olmalı?

Consent should be open and free. There should be an “opt-out” with every message by a click. Consult KVKK and EDPB for more details.

Teslim edilebilirlik nasıl artırılır?

Right opt-in, clean token list, low latency, right send time, backup channel and intact feedback. SPF/DKIM/DMARC are mandatory for email.

İdempotency ve deduplikasyon neden kritik?

Çift mesaj, kötü deneyim demektir. Aynı olayı iki kez işlerseniz, sonuç bir olmalıdır. Aksi takdirde spam gibi durumlarla karşılaşmanız muhtemeldir.

Çok kanalda öncelik nasıl verilir?

First it’s user preference. Then it’s the cost plus speed. Usually, push → in‑app → email → SMS is a good order. If it is a critical security alert, go the fastest route.

Sonuç ve sonraki adımlar

A successful notifications system is a well-architected event-driven stream, with a reliable queue and a fast processor, that powers a clean template, through the right channel, coupled to great tracking. Privacy and permissions are first-class citizens throughout. Start small, measure and improve.

Hızlı kontrol listesi

• Olay akışı kuruldu (Kafka/Pulsar/Streams)
• Kuyruk + retry + DLQ hazır
• İşleyici p95 hedefi: 2–5 sn
• Şablon çok dil ve bölge destekli
• Tercih merkezi + sessiz saatler açık
• FCM/APNs/Web Push entegrasyonları testli
• Gözlemlenebilirlik: OpenTelemetry + Prometheus + Grafana
• KVKK/GDPR uyumu ve kolay çıkış
• A/B test planı ve deney günlüğü

Further reading: FCM, APNs, Web Push, Kafka, OpenTelemetry.