Maʼlumotlarni API orqali sinxronlashtirish

1) Nima uchun sinxronlashtirish kerak va qanday maqsadlar

Domenlarning muvofiqligi: profil, hamyon, kataloglar, limitlar, KYC.
Laglarni kamaytirish: tanqidiy jarayonlar uchun deyarli real-time (to’lovlar, bonuslar).
Barqarorlik: tarmoq/provayderning nosozliklariga duch kelmoqdamiz.
Iqtisodiyot: egress/CPU ni delta va paketlash orqali kamaytiramiz.

Muvaffaqiyat metrikasi: manba va isteʼmolchi oʻrtasidagi lag (s), freshness, dublikatlar ulushi, nizolar foizi, GB/soat sink qiymati.

2) Sinxronlashtirish modellari

2. 1 Pull (polling)

Mijoz oʻzgarishlarni interval bilan soʻraydi.

Afzalliklari: soddaligi, yuklamani nazorat qilish.
Minuslar: lag, «bo’sh» so’rovlar, o’zgarishlar tezligi yuqori bo’lganda o’tkazib yuborish xavfi.
Yaxshilanishlar: If-Modified-Since, Etag/If-None-Match, change_token.

2. 2 Push (webhooks/events)

Manba oluvchiga voqealarni ochib beradi.

Afzalliklari: deyarli real vaqt, so’rovlarni tejash.
Kamchiliklar: retralar bilan yetkazib berish, deduplikatsiya, xavfsizlik (imzo, mTLS).
Talablar: idempotent konsumerlar, eksponensial backoff, replay.

2. 3 CDC/striming (Change Data Capture)

Tranzaksiya/hodisa daftaridagi oʻzgarishlarni koʻrish (Kafka, Debezium).

Afzalliklari: to’liqlik, tartib, masshtab.
Minuslar: murakkablik, operatsiya turlarini nazorat qilish kerak (insert/update/delete/tombstone).

2. 4 Gibrid

Webhooks «trigger» sifatida, polling - fallback sifatida va reconciliation uchun.

3) Inkremental deltalar

3. 1 Watermark (vaqtinchalik belgi)

Mijoz’last _ seen _ ts’ni saqlaydi va’updated _ at> watermark’ni soʻraydi.

Xavflar: bir soatlik dreyf - UTC va NTP dan foydalaning; 1-2 daqiqa (overlap) va ID + version bo’yicha dedupni oling.

3. 2 Change Token / Cursor

Barqaror ketma-ketlik tokeni:’? cursor = eyJvZmZzZXQiOjEwMDB9’.

Ijobiy tomonlari: tartib o’zgarishiga chidamlilik, ko’lami.
Talablar: eskirmaydigan kursorlar, TTL va xavfsiz replay.

3. 3 Raqamlangan ofsetlar (auto-increment)

`id > last_id`. Oddiy, lekin chardlash va «teshiklar» da ketma-ket sinadi.

4) Katta tanlov paginatsiyasi

Keyset/cursor (after = cursor & limit = 1000’- oʻzgarishlarda barqaror.
Offset/limit - oddiy, ammo qimmat va siljishlarga moyil.
Har doim stable sort key (masalan,’(updated_at, id)’) ni koʻrsating.

json
{
"items": [ { "id": "u_1", "updated_at": "2025-11-03T16:59:10Z" } ],
"next_cursor": "eyJ1cGRhdGVkX2F0IjoiMjAyNS0xMS0wM1QxNjo1OToxMFoifQ==",
"has_more": true
}

5) O’zgarishlar semantikasi: upsert, merge, delete

5. 1 Upsert/merge

’PUT/resource/{ id}’ - toʻliq almashtirish.
’PATCH/resource/{ id}’ - qisman yangilanish (validatsiyali merge patchlar).
Hamma uchun idempotentlik’idempotency-Key’.

5. 2 Oʻchirish

Soft delete (’deleted = true’,’deleted _ at’) - tarixni saqlaymiz; sink tombstone beradi.
Hard delete - yoʻqolishdan oldin’deleted’hodisasini bering.

json
{ "id":"u_1", "event":"deleted", "deleted_at":"2025-11-03T17:00:00Z" }

6) Versiyalar va raqobatni nazorat qilish

6. 1 ETag/If-Match (optimistik blokirovkalar)

Oʻqish’ETag’ni qaytaradi:’v123’.
’If-Match’ ni yangilash:’v123’- «yo’qolgan yangilanishlardan» himoya qilish.
409 Conflict s’error _ code: "CONFLICT_VERSION"'.

6. 2 Yozuvlarni versiya qilish

’version ’/’ updated _ at’ maydoni - delta va deduplikatsiya hisobida.

6. 3 Mojarolar

Siyosatlar: last-write-wins, server-wins, merge-strategy (masalan, summalar → qo’shimcha, bayroqlar → manbaning ustuvorligi).

7) Buyurtma va dekuplikatsiya

7. 1. Yetkazib berish tartibi

Kafolatlar: at-least-once plyus idempotentlik → de-fakto standart.
Tanqidiy pul oqimlari uchun - idempotency store orqali exactly-once effektlari.

7. 2 Idempotentlik kalitlari

Domen maydonlari tarkibi:’source _ id’event _ type’sequence’.
TTL saqlash 24-72 soat (yoki SLAda ko’proq).

7. 3 De-duplikatsiya

Oxirgi qoʻllanilgan version/seqni qabul qiluvchiga saqlang; eskilarini tashlang.

8) Takrorlash, taymautlar, backoff

Retriable: 5xx/429/408/taymautlar; Non-retriable: 400/401/403/404/409/422/410/412.
Eksponensial backoff + jitter: 1s, 2s, 4s... 30-60s gacha.
Retry-After uchun hurmat 429/503.
Mijozlar taymautlari: ulanish 3-5s, umumiy so’rov 10-30s; urinishlarning umumiy limiti 3-6.

9) Laglar va SLAni nazorat qilish

9. 1 SLI/SLO

SLI Lag:’occurred _ at’va’isteʼmolchida qoʻllanilgan’orasidagi median/p95 lag.
SLO: masalan,’p95 lag ≤ 60s (28d)’, "yo’qolgan hodisalar ulushi = 0", "dublikatlar ulushi ≤ 0. 01%».
Error Budget: Biz relizlarga/tajribalarga sarflaymiz.

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 (solishtirmalar) va backfill

Kunduzgi/soatlik solishtirmalar: oynalar bo’yicha jami ko’rsatkichlar/xeshlar.
’GET/reconciliation? from =... & to =...’nazorat summalari va tafovutlarni qaytaradi.
Backfill: tarixiy ma’lumotlarni DDOS manbasiz kursorli qutilar bilan xavfsiz yuklash; limitlarga rioya qiling.

11) Sxemalar va misollar

11. 1 Webhook hodisalar (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 Inkremental tanlov (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) Xavfsizlik va komplayens

Auth: OAuth2 scopes/JWT; sink kanallari uchun - talab bo’yicha mTLS.
Imzolar: HMAC vebxuk sarlavhalari, sirlarni almashtirish.
PII-minimallashtirish, loglarda niqoblash; GDPR/DSAR: tushirish/olib tashlash.
RBAC/ABAC: tenant/tashkilot bo’yicha kirish, qat’iy kvotalar.

13) Kuzatuv va loglar

Лейблы: `env`, `service`, `tenant`, `source`, `cursor`, `seq`, `event_type`.
Korrelyatsiya:’trace _ id’dan → loglar va treklarga foydalaning.
Deshbordlar: lag, backlog, kursor tezligi, turlar bo’yicha xatolar, 429/5xx, qiymati (egress/min).

14) FinOps: sinxronlashtirish qiymati

Paketlash (batch size 100-1000) + siqish (gzip/br).
Oʻzgarmagan sahifalar uchun kesh va ETag.
Yupqa payload’lar: faqat oʻzgartirilgan maydonlar, talab boʻyicha toʻliq manbaga havola.
Backfill uchun parallellik chegaralari va «tungi derazalar».

15) Test sinovi va sifat

15. 1 Kontraktlar va salbiy keyslar

JSON sxemalarini, majburiy maydonlarni, barqarorlikni tasdiqlang’error _ code’.
Testlar: out-of-order, dublikatlar, voqealarni o’tkazib yuborish, versiyalar to’qnashuvi, 429/5xx.

15. 2 Chaos/oʻyinlar

Inyeksiya: tarmoq kechikishlari, drop 10-30% hodisalar, reorder.
Mezonlar: tartib/yaxlitlikni saqlab qoldingizmi? yo’qotishlar yo’qmi? SLO doirasida lag?

16) Joriy etish chek-varaqasi

• Model (push/pull/hybrid) va haqiqat manbai tanlangan.
• Inkremental deltalar: watermark yoki cursor/token.
• Paginatsiya: barqaror navli cursor/keyset.
• Idempotency-store, kalitlar va TTL; dedup’(id, version/seq)’.
• ETag/If-Match va ziddiyat siyosati (LWW/server-wins/merge).
• Retry/backoff/jitter, hurmat’Retry-After’.
• lag/backlog/duplicates/conflicts metriklari, dashbordlar va alertlar.
• Reconciliation API + kundalik taqqoslash.
• Xavfsizlik: OAuth2/JWT, vebxuk imzolari, mTLS, PII siyosati.
• FinOps: batch + compression, parallellik limitlari, egress-kvotalar.
• Test toʻplami: reorder, duplicates, outages, backfill.

17) Joriy etish rejasi (3 ta iteratsiya)

1. MVP (1-2 hafta):

Cursor-paginatsiya, watermark-delta, idempotent upsert, bazaviy metrika lag/backlog, retry + backoff.

2. Scale (2-3 hafta):

Webhooks trigger + polling-fallback, HMAC imzolari, reconciliation, ETag/If-Match, dashbordlar va lag bo’yicha burn-alertlar sifatida.

3. Pro (3-4 hafta):

Issiq domenlar uchun CDC/striming (Kafka/Debezium), auto-backfill, DR stsenariylari, FinOps-optimallashtirish (batch/brotley), SLA lag bo’yicha va hisobot.

18) Mini-FAQ

Nima tanlash kerak: watermark yoki cursor?
Cursor/keyset reorder va masshtablarga chidamli; watermark boshlash uchun osonroq, lekin overlap va dedup qo’shing.

exactly-once kerakmi?
Umuman olganda, qimmat. Amaliyot - at-least-once + idempotentlik; exactly-once - faqat pul effektlari uchun.

Qanday qilib nizolarni minimallashtirish mumkin?
ETag/If-Match dan foydalaning, merge maydonlarini loyihalashtiring, «yashirin» nojo’ya ta’sirlardan saqlaning.

Jami

Ishonchli sinxronizatsiya - bu inkremental deltalar + to’g’ri paginatsiya + kuzatish, yorug’lik va tejamkor transport bilan kuchaytirilgan versiyalarni nazorat qilish va idempotentlik. To’g’ri modelni tanlang (push/pull/CDC), SLOni lagga o’rnating, mojaro siyosati va «iflos» stsenariy sinovlarini joriy qiling - va sizning ma’lumotlaringiz oldindan aytib bo’lmaydigan, barqaror va tejamkor bo’ladi.