Trading alert system development üçün əsas prinsip sadədir: düzgün bazar siqnalı istifadəçiyə vaxtında, yalnız bir dəfə və başa düşülən kontekstdə çatmırsa, məhsul etibarlı deyil. Forex və ya kripto platformasında istifadəçi yalnız “BUY” və ya “SELL” mətnini deyil, hansı instrument, hansı timeframe, hansı qiymət, hansı qayda və hansı vaxt əsasında siqnalın yarandığını görməlidir. Bununla yanaşı, çatdırılma sistemi gecikmə, offline cihaz, provayder limiti və təkrarlanan sorğular zamanı idarəolunan davranmalıdır.

Bildirişləri ticarət nəticəsi və ya mənfəət vədi kimi yox, məlumat məhsulu kimi dizayn edin. Siqnal bazar vəziyyətinin və ya müəyyən qaydanın nəticəsidir; istifadəçi isə öz araşdırmasına, risk limitinə və yerli qaydalara uyğun müstəqil qərar verir. Bu sərhəd həm məhsul mətnində, həm onboarding-də, həm də bildirişin özündə aydın olmalıdır.

Etibarlı trading alerts architecture hansı mərhələlərdən ibarətdir?

Dayanıqlı arxitektura siqnal hesablanması ilə mesaj göndərişini bir-birindən ayırır. Praktik axın belə görünür:

  1. Məlumatın qəbulu: qiymət, candle, order-book, iqtisadi təqvim və ya istifadəçi tərəfindən izlənən qaydalar daxil olur.
  2. Normallaşdırma və təzəlik yoxlaması: simvol, timeframe, timestamp və mənbə formatları vahid modelə çevrilir; köhnəlmiş və ya ardıcıllığı pozulmuş məlumat kənarlaşdırılır.
  3. Siqnal mühərriki: qaydaları və ya analitik modeli icra edir, səbəbi və giriş məlumatlarının versiyasını qeyd edir.
  4. Alert qərarı: siqnalın istifadəçinin abunəliyinə, sakit saatlarına, kanal seçiminə və tezlik limitinə uyğun olub-olmadığını yoxlayır.
  5. Outbox və növbə: çatdırılacaq hadisəni dayanıqlı şəkildə saxlayır və kanal worker-lərinə ötürür.
  6. Kanal adaptorları: push, e-poçt, Telegram və in-app inbox üçün provayderə uyğun göndəriş edir.
  7. Status və müşahidə: qəbul edildi, provayderə göndərildi, müvəqqəti xəta, daimi xəta və mümkün olduqda cihaz/istifadəçi təsdiqi ayrıca izlənir.

Bu bölünmə kritikdir: push provayderində problem olduqda siqnal mühərriki dayanmalı deyil. Əksinə, siqnal hadisəsi etibarlı outbox-da qalır, çatdırılma isə retry siyasəti ilə ayrıca bərpa olunur. POLADO-nun FinTech və trading sistemləri xidməti bu tip bazar məlumatı, istifadəçi workflow-ları və istehsal mühitinə uyğun inteqrasiyalar üçün məhsul yönümlü mühəndislik yanaşmasını əhatə edir.

Siqnalın təzəliyini və izah edilə bilməsini qoruyun

“Real-time” sözü ölçülməyən vəd olmamalıdır. Hər siqnal üçün ən azı bu zaman damğalarını saxlayın: mənbə hadisəsinin vaxtı, sistemin hadisəni qəbul etmə vaxtı, qaydanın hesablanma vaxtı, növbəyə yazılma vaxtı və kanal provayderinə göndəriş vaxtı. Bu məlumatla “bildiriş gec gəldi” şikayətini konkret mərhələyə bağlamaq mümkündür.

Məsələn, 5 dəqiqəlik candle bağlanışına əsaslanan qayda yalnız candle-ın həqiqətən bağlandığı təsdiqlənəndən sonra işləməlidir. Qismən formalaşmış candle üzərində çıxan siqnal sonradan yoxa çıxa bilər. Hər alert payload-ında instrument, timeframe, siqnal vaxtı, müşahidə edilən qiymət, qayda və ya model versiyası, məlumat mənbəsi saxlanmalıdır. Siqnal sonradan yenidən hesablansa, istifadəçiyə köhnə qərarın nə ilə yarandığını izah etmək və mühəndis komandaya hadisəni bərpa etmək mümkün olur.

Siqnal identifikatoru və deduplikasiya

Eyni bazar hərəkəti birdən çox data update, worker retry-si və ya provayder timeout-u yarada bilər. Buna görə “göndərmək” əməliyyatı ən azı effectively-once davranışına yaxınlaşdırılmalıdır. Bunun üçün deterministik alert açarı yaradın, məsələn:

rule_version + instrument + timeframe + candle_close_time + direction + subscriber_id

Bu açarı unikal indekslə outbox cədvəlində saxlayın. Eyni siqnal yenidən emal edilərsə, ikinci mesaj yaranmır. Amma qiymət hədəfi dəyişibsə və ya istifadəçi yeni kontekstə ehtiyac duyursa, həmin hadisə üçün ayrıca update və ya invalidated statusu yaradın; ilkin alerti səssizcə dəyişdirməyin.

İstifadəçi seçimləri sadəcə UI elementi deyil

Forex alert platform və crypto signal notification system üçün abunə modeli çatdırılma yükünü və istifadəçi etibarını birbaşa müəyyən edir. İstifadəçi aşağıdakıları idarə edə bilməlidir:

  • izlənən instrumentlər, bazarlar və timeframe-lər;
  • siqnal kateqoriyası: qiymət səviyyəsi, indikator, xəbərə bağlı hadisə, analitik ideya;
  • kanal prioriteti: push, Telegram, e-poçt və in-app inbox;
  • sakit saatlar, timezone və maksimum gündəlik/saatlıq alert sayı;
  • eyni tip siqnalların birləşdirilməsi və ya xülasə formatı;
  • abunəliyin aktivliyi, cihaz tokeni və Telegram chat icazəsi.

Bu seçimləri siqnal çıxandan sonra yox, alert qərar mərhələsində tətbiq edin. Beləliklə, bir qlobal siqnal minlərlə istifadəçi üçün ayrıca, audit edilə bilən çatdırılma qərarına çevrilir. İn-app inbox isə vacib ehtiyat qatıdır: push görünməsə belə istifadəçi tətbiqə daxil olanda son hadisələri görə bilir.

Push, e-poçt və Telegram üçün fərqli çatdırılma siyasəti qurun

Kanalların semantikası eyni deyil. Push sorğusunun provayder tərəfindən qəbul edilməsi cihazın mesajı oxuduğunu, hətta mütləq ekranda göstərildiyini bildirmir. Web Push standartında da qəbul cavabı son istifadəçi cihazına çatdırılma demək deyil; TTL müddəti və uyğun hallarda receipt mexanizmləri ayrıca nəzərə alınmalıdır. Buna görə məhsul analitikasında “sent”, “provider accepted”, “delivery confirmed where available” və “opened” vəziyyətlərini qarışdırmayın.

TTL-ni alertin iqtisadi və məhsul dəyərinə görə seçin. Bir qiymət səviyyəsi qısa müddət aktualdırsa, saatlarla gecikmiş push daha çox zərər verə bilər. Digər tərəfdən, bazar xülasəsi və ya təqvim xatırlatması daha uzun saxlanma müddətinə uyğun ola bilər. Eyni istifadəçiyə gözləyən köhnə qiymət alertlərini yenisi ilə əvəzləmək üçün collapse və ya coalescing yanaşmasından istifadə edin; amma entry, stop-loss və take-profit kimi fərqli kontekstli siqnalları yanlışlıqla birləşdirməyin.

Telegram adaptorunda chat identifikatorunun etibarlılığını, mesaj ölçüsünü, formatlaşdırma xətalarını və rate-limit cavablarını idarə edin. E-poçt daha dayanıqlı audit kanalı və gündəlik xülasə üçün münasibdir, amma saniyəlik ticarət qərarları üçün primary real-time kanal kimi qəbul edilməməlidir.

Retry, rate limit və dead-letter queue necə işləməlidir?

Retry bütün xətalar üçün düzgün cavab deyil. Autentifikasiya problemi, silinmiş cihaz tokeni, etibarsız chat və ya yanlış payload adətən daimi xətadır: retry etməyin, endpoint-i deaktiv edin və lazım olduqda istifadəçidən yenidən qoşulma istəyin. Timeout, 429 və bəzi 5xx cavabları isə müvəqqəti xəta ola bilər.

Müvəqqəti xətalarda exponential backoff və random jitter tətbiq edin, provayderin Retry-After göstərişinə əməl edin və maksimum yaş limiti təyin edin. Məsələn, 30 dəqiqəlik köhnə “breakout” alertini dəfələrlə yenidən göndərmək əvəzinə onu expired edin. Təkrarlanan uğursuz göndərişlər dead-letter queue-ya keçməli, amma bu queue görünməz arxiv olmamalıdır: dashboard, səbəb kodları, replay üçün təhlükəsiz alət və növbətçi komanda xəbərdarlığı lazımdır.

Market signal delivery monitoring üçün nəyi ölçmək lazımdır?

Yalnız “göndəriş sayı” kifayət deyil. Dashboard-da aşağıdakı ölçüləri kanal, instrument qrupu, region və alert növü üzrə izləyin:

  • mənbə hadisəsindən outbox-a qədər və outbox-dan provayderə qədər p50/p95/p99 gecikmə;
  • siqnal yaratma, deduplikasiya, istifadəçi tərəfindən susdurma və expiration sayı;
  • kanal üzrə qəbul, müvəqqəti xəta, daimi xəta və retry nisbəti;
  • növbə dərinliyi, ən köhnə mesajın yaşı və worker throughput-u;
  • aktiv endpoint faizi, token/chata bağlı invalidation faizi;
  • hər istifadəçiyə düşən alert həcmi və rate-limit səbəbi ilə basdırılan hadisələr.

Hədəf yalnız aşağı latency deyil, mənalı latency-dir: siqnalın hələ aktual olduğu müddətdə düzgün istifadəçiyə çatması. SLO-ları alert siniflərinə bölün. Məsələn, kritik qiymət səviyyəsi, gündəlik xülasə və məhsul xəbəri eyni çatdırılma məqsədinə malik deyil. Hər incident üçün də trace ID ilə mənbə hadisəsindən kanal cavabına qədər iz buraxın.

Buraxılışdan əvvəl yoxlama siyahısı

  • Hər siqnalın qayda/model və məlumat versiyası qeyd olunurmu?
  • Köhnə və ardıcıllığı pozulmuş bazar məlumatı rədd edilirmi?
  • Deduplikasiya açarı və unikal outbox qeydi varmı?
  • İstifadəçi seçimləri, timezone və sakit saatlar server tərəfində tətbiq edilirmi?
  • TTL, expiration, collapse və retry siyasəti alert növünə görə fərqlənirmi?
  • 429 və 5xx üçün backoff+jitter, daimi xətalar üçün endpoint cleanup varmı?
  • İn-app inbox və support üçün audit tarixçəsi mövcuddurmu?
  • Latency, queue age, error rate və delivery status üçün alerting qurulubmu?
  • Risk disclaimer-ları aydın, görünən və məhsulun faktiki davranışı ilə uyğun gəlirmi?

POLADO, FT10 və ESFX kimi FinTech yönümlü məhsullardan gələn təcrübəni web, mobil, analitika və notification workflow-larına tətbiq edir. Mövcud siqnal məhsulunuzu audit etmək, yeni arxitekturanı planlamaq və ya etibarlı çatdırılma qatını qurmaq istəyirsinizsə, texniki dəstək və konsaltinq üçün POLADO ilə əlaqə saxlayın.