API vasitəsilə məlumatların sinxronlaşdırılması
1) Niyə sinxronizasiya lazımdır və hansı məqsədlər
Domen uyğunluğu: profil, cüzdan, kataloqlar, limitlər, KYC.
Lag azaldılması: kritik proseslər üçün demək olar ki, real vaxt (ödənişlər, bonuslar).
Dayanıqlılıq: hadisələri itirmədən şəbəkə/provayder fasilələri yaşayırıq.
İqtisadiyyat: delta və paket vasitəsilə egress/CPU minimuma endirmək.
Uğur göstəriciləri: mənbə və istehlakçı arasında lag (s), freshness, dublikat payı, münaqişə faizi, GB/saat ming dəyəri.
2) Sinxronizasiya modelləri
2. 1 Pull (polling)
Müştəri intervalla dəyişiklik tələb edir.
Üstünlüklər: sadəlik, yük nəzarəti.
Mənfi cəhətləri: lag, «boş» sorğular, yüksək dəyişmə sürəti ilə keçid riski.
Təkmilləşdirmə: If-Modified-Since, Etag/If-None-Match, change_token.
2. 2 Push (webhooks/events)
Mənbə hadisələri alıcıya çatdırır.
Üstünlüklər: demək olar ki, real vaxt, qənaət sorğular.
Mənfi cəhətləri: retralar, deduplikasiya, təhlükəsizlik (imza, mTLS) ilə çatdırılma lazımdır.
Tələblər: idempotent konsumerlər, eksponent backoff, replay.
2. 3 CDC/axın (Change Data Capture)
Əməliyyat log/hadisə jurnalı (Kafka, Debezium) dəyişiklik görüntüsü.
Üstünlüklər: dolğunluq, nizam, miqyas.
Mənfi cəhətləri: mürəkkəblik, əməliyyat növlərinə nəzarət etmək lazımdır (insert/update/delete/tombstone).
2. 4 Hibrid
Webhooks «trigger» kimi, polling - fallback kimi və reconciliation üçün.
3) İnkremental deltalar
3. 1 Watermark (müvəqqəti etiket)
Müştəri 'last _ seen _ ts' saxlayır və 'updated _ at> watermark' tələb edir.
Risklər: saat sürüklənməsi - UTC və NTP istifadə edin; 1-2 dəq və ID + version ilə üst-üstə düşən pəncərəni (overlap) götürün.
3. 2 Change Token / Cursor
Sabit ardıcıllıq tokeni: '? cursor = eyJvZmZzZXQiOjEwMDB9'.
Üstünlüklər: nizamın dəyişməsinə dözümlülük, miqyas.
Tələblər: tükənməz kursorlar, TTL və təhlükəsiz replay.
3. 3 Nömrələnmiş ofset (auto-increment)
`id > last_id`. Sadə, lakin ardıcıllıqla dəliklər və «deşiklər» zamanı qırılır.
4) Böyük seçimlərin paginasiyası
Keyset/cursor (tercihen): '? after = cursor & limit = 1000' - dəyişdikdə sabitdir.
Offset/limit - sadə, lakin bahalı və dəyişməyə məruz qalır.
Həmişə stable sort key (məsələn, '(updated_at, id)').
json
{
"items": [ { "id": "u_1", "updated_at": "2025-11-03T16:59:10Z" } ],
"next_cursor": "eyJ1cGRhdGVkX2F0IjoiMjAyNS0xMS0wM1QxNjo1OToxMFoifQ==",
"has_more": true
}5) Dəyişiklik semantikası: upsert, merge, delete
5. 1 Upsert/merge
'PUT/resource/{ id}' tam əvəzedicidir.
'PATCH/resource/{ id}' - qismən yeniləmə.
Idempotance 'Idempotency-Key' bütün write üçün.
5. 2 Silinir
Soft delete (sahə 'deleted = true', 'deleted _ at') - tarixi saxlayın; sink tombstone verir.
Hard delete - yoxa çıxmadan əvvəl 'deleted' hadisəsini verin.
json
{ "id":"u_1", "event":"deleted", "deleted_at":"2025-11-03T17:00:00Z" }6) Versiyası nəzarət və rəqabət
6. 1 ETag/If-Match (optimist bloklama)
Oxu qaytarır 'ETag: «v123»'.
«If-Match» ilə yeniləmə: «v123» '- «itirilmiş yeniləmələrdən» qorunma.
Münaqişə zamanı - 409 Conflict ilə 'error _ code: "CONFLICT_VERSION"'.
6. 2 Qeydlərin versiyası
'version '/' updated _ at' sahəsi - delta və duplikasiya hesablamasında.
6. 3 Münaqişələr
Siyasətlər: last-write-wins, server-wins, merge-strategy (məsələn, məbləğlər → əlavə, bayraqlar → prioritet mənbə).
7) Sifariş və duplikasiya
7. 1 Çatdırılma qaydası
Zəmanət: at-least-once plus idempotent → de-fakto standart.
Kritik pul axını üçün - idempotency store vasitəsilə exactly-once effektləri.
7. 2 İdempotentlik açarları
Domen sahələrinin tərkibi: 'source _ id' event _ type 'sequence'.
TTL saxlama 24-72 saat (və ya daha çox SLA).
7. 3 Dekuplikasiya
Son tətbiq version/seq-i alıcıda saxlayın; köhnə atmaq.
8) Təkrar, taymaut, backoff
Retriable: 5xx/429/408/vaxt; Non-retriable: 400/401/403/404/409/422/410/412.
Eksponent backoff + jitter: 1s, 2s, 4s... 30-60s qədər.
Retry-After 429/503 üçün hörmət.
Müştəri vaxtı: 3-5s əlaqə, 10-30s ümumi sorğu; ümumi cəhd limiti 3-6.
9) Lag və SLA nəzarət
9. 1 SLI/SLO
SLI Lag: orta/p95 lag arasında 'occurred _ at' və «istehlakçıda tətbiq olunur».
SLO: məsələn, 'p95 lag ≤ 60s (28d)', "itirilmiş hadisələrin payı = 0", "təkrarların payı ≤ 0. 01%».
Error Budget: Buraxılışlara/təcrübələrə sərf edirik.
9. 2 Metrika
`sync_lag_seconds`, `events_received_total`, `events_applied_total`, `duplicates_total`, `conflicts_total`, `retries_total`, `backlog_size`, `cursor_advance_rate`.
10) Reconciliation və backfill
Gündüz/saat yoxlamalar: pəncərələr üzrə ümumi göstəricilər/hash.
API yoxlama: 'GET/reconciliation? from =... & to =... 'nəzarət məbləğləri və uyğunsuzluqları qaytarır.
Backfill: DDOS mənbəyi olmadan kursor ilə paket tarixi məlumatların təhlükəsiz yüklənməsi; limitlərə riayət edin.
11) Sxemlər və nümunələr
11. 1 Webhook hadisələr (signed)
json
{
"event": "user. updated",
"id": "evt_01HX",
"occurred_at": "2025-11-03T18:00:05Z",
"sequence": 123456,
"data": { "id": "u_1", "email": "a@b. com", "updated_at": "2025-11-03T18:00:02Z" }
}- `X-Signature: sha256=
- `X-Event-Id: evt_01HX`
- `X-Retry: 0..N`
11. 2 Artımlı nümunə (polling)
`GET /v1/users? updated_after=2025-11-03T17: 58:00Z&cursor=...&limit=1000`
11. 3 Idempotent upsert
POST /v1/users
Idempotency-Key: upsert-u_1-20251103T1800Z
{ "id":"u_1","email":"a@b. com","version":124 }
→ 201/200 (stable)12) Təhlükəsizlik və uyğunluq
Auth: OAuth2 scopes/JWT; sink kanalları üçün - mTLS tələb.
Başlıqlar: HMAC başlıqlar üçün webhook, sirlərin rotasiyası.
PII-minimallaşdırma, log maskalanması; GDPR/DSAR: boşaltma/çıxarılması.
RBAC/ABAC: tenant/təşkilatlar, ciddi kvotalar.
13) Müşahidə və log
Лейблы: `env`, `service`, `tenant`, `source`, `cursor`, `seq`, `event_type`.
Korrelyasiya: Girişdən 'trace _ id' → log və traslarda tətbiq edin.
Dashboard: lag, backlog, kursor sürəti, tip səhvləri, 429/5xx, dəyəri (egress/dəq).
14) FinOps: sinxronizasiya dəyəri
Paketləmə (batch size 100-1000) + sıxılma (gzip/br).
Dəyişməyən səhifələr üçün caching və ETag.
Slim payload ': Yalnız dəyişdirilmiş sahələr, tələb olunan tam resursa keçid.
Paralellik limitləri və backfill üçün «gecə pəncərələri».
15) Test və keyfiyyət
15. 1 Müqavilələr və mənfi hallar
JSON sxemlərini, məcburi sahələri, sabitliyi təsdiqləyin 'error _ code'.
Testlər: out-of-order, dublikatlar, hadisələrin atlanması, versiya toqquşması, 429/5xx.
15. 2 Chaos/oyunlar
Enjeksiyonlar: şəbəkə gecikmələri, drop 10-30% hadisələr, reorder.
Meyarlar: qaydanı/bütövlüyünü saxladınız? itki yoxdur? SLO daxilində lag?
16) Giriş çek siyahısı
- Model seçildi (push/pull/hybrid) və həqiqət mənbəyi.
- Artımlı deltalar: watermark və ya cursor/token.
- Pagination: sabit çeşidi ilə cursor/keyset.
- Idempotency-store, açarları və TTL; dedup '(id, version/seq)'.
- ETag/If-Match və Konflikt Siyasəti (LWW/server-wins/merge).
- Retry/backoff/jitter, hörmət 'Retry-After'.
- lag/backlog/duplicates/conflicts metrik, dashboard və alert.
- Reconciliation API + gündəlik yoxlama.
- Təhlükəsizlik: OAuth2/JWT, vebhuk imzaları, mTLS, PII siyasəti.
- FinOps: batch + compression, paralellik limitləri, egress-kvotalar.
- Testlər dəsti: reorder, duplicates, outages, backfill.
17) Tətbiq planı (3 iterasiya)
1. MVP (1-2 həftə):
Cursor-pagination, watermark-delta, idempotent upsert, lag/backlog, retry + backoff əsas metriklər.
2. Scale (2-3 həftə):
Webhooks trigger + polling-fallback, HMAC imzalar, reconciliation, ETag/If-Match, dash-board və burn-alert kimi.
3. Pro (3-4 həftə):
Hot Domain üçün CDC/Streaming (Kafka/Debezium), auto-backfill, DR ssenariləri, FinOps-optimizasiya (batch/brotley), SLA lag və hesabat.
18) Mini-FAQ
Nə seçmək lazımdır: watermark və ya cursor?
Cursor/keyset reorder və miqyasına daha davamlı; watermark başlamaq üçün daha asandır, lakin overlap və dedup əlavə edin.
exactly-once lazımdır?
Ümumiyyətlə, bahadır. Təcrübə - at-least-once + idempotentlik; exactly-once - yalnız pul effektləri üçün.
Münaqişələri necə minimuma endirmək olar?
ETag/If-Match istifadə edin, sahələrdə merge dizayn edin, «gizli» yan təsirlərdən çəkinin.
Yekun
Etibarlı sinxronizasiya inkremental deltalar + düzgün paginasiya + müşahidə, parlaq və qənaətli nəqliyyat ilə gücləndirilmiş idempotentlik və nəzarət versiyalarıdır. Uyğun bir model seçin (push/pull/CDC), SLO-ları yığın, münaqişə siyasətlərini və «çirkli» ssenarilərin testlərini tətbiq edin və məlumat mübadiləsi proqnozlaşdırıla bilən, sabit və qənaətli olacaq.