API üzerinden veri senkronizasyonu

1) Senkronizasyon neden gereklidir ve hedefler nelerdir

Etki alanı tutarlılığı: profil, cüzdan, dizinler, limitler, KYC.
Gecikmeleri azaltmak: kritik süreçler için neredeyse gerçek zamanlı (ödemeler, bonuslar).
Esneklik: Olay kaybı olmadan ağ/sağlayıcı kesintileri yaşamak.
Ekonomi: Deltalar ve paketleme yoluyla çıkış/CPU'yu en aza indirin.

Başarı ölçümleri: Kaynak ve tüketici arasındaki gecikme, tazelik, kopya oranı, çakışmaların yüzdesi, GB/saatlik mavi maliyeti.

2) Senkronizasyon modelleri

2. 1 Çekme (oylama)

Müşteri aralıklarla değişiklik talep eder.

Artıları: basitlik, yük kontrolü.
Eksileri: gecikme, "boş" anketler, yüksek bir değişim oranında atlama riski.
İyileştirmeler: If-Modified-Since, Etag/If-None-Match, change_token.

2. 2 Push (webhooks/etkinlikler)

Kaynak olayları alıcıya iletir.

Artılar: neredeyse gerçek zamanlı, anket ekonomisi.
Eksileri: retrays, veri tekilleştirme, güvenlik (imza, mTLS) ile teslim gerekir.
Gereksinimler: idempotent tüketiciler, üstel geri dönüş, tekrar oynatma.

2. 3 CDC/Akış (Veri Yakalama Değişikliği)

İşlem günlüğü/olay günlüğündeki değişikliklerin anlık görüntüsü (Kafka, Debezium).

Artılar: bütünlük, düzen, ölçek.
Eksileri: Karmaşıklık, işlem türleri üzerinde kontrol sahibi olmanız gerekir (insert/update/delete/tombstone).

2. 4 Hibrit

Webhooks bir "tetikleyici'olarak, bir geri dönüş olarak yoklama ve uzlaşma için.

3) Artımlı deltalar

3. 1 Filigran (zaman damgası)

İstemci 'last _ seen _ ts' depolar ve 'updated _ at> watermark' ister.

Riskler: saat sürüklenme - UTC ve NTP kullanın; 1-2 dakika çakışma penceresi ve ID + sürümüne göre dedup alın.

3. 2 Belirteci/İmleci Değiştir

Kararlı dizi belirteci: '? İmleç = eyJvZmZzZXQiOjEwMDB9 '.

Artıları: düzen, ölçek değiştirmek için esneklik.
Gereksinimler: Tükenmemiş imleçler, TTL ve güvenli tekrar.

3. 3 Numaralı uzaklıklar (otomatik artış)

'id> last_id'. Basit, ancak parçalarken ve dizide "delikler" olduğunda parçalanır.

4) Büyük örnek sayfalama

Keyset/imleç (tercih edilen): '? = imlecin ardından & limit = 1000 '- değişikliklerle kararlı.
Ofset/limit - basit, ancak pahalı ve vardiyalara tabidir.
Her zaman kararlı bir sıralama anahtarı belirtin (örneğin, '(updated_at, id)').

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

5) Semantiği değiştir: upsert, merge, delete

5. 1 Uppert/birleştirme

'PUT/resource/{ id}' tam bir değişimdir.
'PATCH/resource/{ id}' - kısmi güncelleme (yamaları doğrulama ile birleştirme).
Idempotency tarafından 'Idempotency-Key' Tüm yazmak için.

5. 2 Silme işlemleri

Yumuşak silme (alan 'silindi = true', 'silindi _ at') - geçmişi kaydedin; lavabo mezar taşı verir.
Sert silme - olay kaybolmadan önce 'silinmiş' verin.

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

6) Sürüm kontrolü ve rekabet

6. 1 ETag/If-Match (iyimser kilitler)

Okuma döndürür 'ETag: "v123"'.
'If-Match: "v123'den güncelleme -' kayıp güncellemelere 'karşı koruma.
Çakışma durumunda - 409 Conflict with 'error _ code: "CONFLICT_VERSION"'.

6. 2 Kayıtların çevrilmesi

'Version'/' updated _ at' alanı - delta hesaplamasında ve veri tekilleştirmede.

6. 3 Çatışmalar

Politikalar: Son-yazma-kazanma, sunucu-kazanma, alanlara göre birleştirme-strateji (örneğin, toplamlar - katkı, bayraklar - kaynak önceliği).

7) Sipariş ve veri tekilleştirme

7. 1 Teslimat prosedürü

Garantiler: en az bir kez artı idempotency - fiili standart.
Kritik nakit akışları için - idempotency mağazası aracılığıyla tam bir kez etkiler.

7. 2 Idempotence tuşları

Etki alanı alanlarının bileşimi: 'source _ id' event _ type 'sequence'.
Depolama TTL 24-72 saat (veya SLA'larda daha fazla).

7. 3 Veri tekilleştirme

Alıcıya uygulanan son sürümü/seq'i kaydedin; büyükleri bırak.

8) Tekrarlar, zaman aşımları, geri alma

Yeniden kullanılabilir: 5xx/429/408/zaman aşımları; Yeniden kullanılamaz: 400/401/403/404/ 409/422/410/412.
Üstel geri dönüş + jitter: 1s, 2s, 4s... 30-60'lara.
Retry-429/503 için saygıdan sonra.
Müşteri zaman aşımları: bağlantı 3-5'ler, genel istek 10-30'lar; Toplam 3-6 deneme limiti.

9) Gecikmeler ve SLA kontrolü

9. 1 SLI/SLO

SLI Lag: Medyan/p95 'occured _ at've' consumer olarak uygulanan 'arasında gecikme.
SLO: örneğin, 'p95 lag ≤ 60s (28d)', "share of lost events = 0", "share of duplicates ≤ 0. 01%».
Hata Bütçesi: sürümler/deneyler için harcama.

9. 2 Metrikler

'synnc _ lag _ seconds', 'events _ received _ total', 'events _ applied _ total', 'duplicates _ total', 'conflicts _ total', 'retries _ total', 'backlog _ size', 'cursor _ advance _ rate'.

10) Uzlaşma ve dolgu

Gün/saat mutabakatları: toplamlar/pencere karmaları.
Mutabakat API: 'GET/uzlaşma? =... &'dan ='a... 'checksum ve varyansları döndürür.
Geri doldurma: Bir DDOS kaynağı olmadan, bir imleç ile geçmiş verilerin gruplar halinde güvenli bir şekilde yeniden yüklenmesi; Sınırlara uyun.

11) Şemalar ve örnekler

11. 1 Webhook etkinlikleri (imzalı)

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ı örnekleme (yoklama)

'GET/v1/kullanıcıları? updated_after=2025-11-03T17: 58:00Z&cursor=...&limit=1000'

11. 3 Idempotent uppert

POST /v1/users
Idempotency-Key: upsert-u_1-20251103T1800Z
{ "id":"u_1","email":"a@b. com","version":124 }
→ 201/200 (stable)

12) Güvenlik ve uyumluluk

Auth: OAuth2 kapsamları/JWT; Bağlantı kanalları için - talep üzerine mTLS.
Altyazılar: Webhook'lar için HMAC başlıkları, dönen sırlar.
PII minimizasyonu, günlüklerde maskeleme; GDPR/DSAR Yükleme/Silme.
RBAC/ABAC: kiracı/kuruluş erişimi, katı kotalar.

13) Gözlemlenebilirlik ve günlükler

Лейблы: 'env', 'service', 'tenant', 'source', 'cursor', 'seq', 'event _ type'.
Korelasyon: Girişten gelen 'trace _ id', günlüklere ve izlere uygulanır.
Panolar: gecikme, birikme, imleç hızı, tür hataları, 429/5xx, maliyet (çıkış/dakika).

14) FinOps: senkronizasyon maliyeti

Toplu işleme (parti boyutu 100-1000) + sıkıştırma (gzip/br).
Değiştirilmemiş sayfalar için önbelleğe alma ve ETag.
İnce yükler: yalnızca değiştirilen alanlar, talep üzerine tam bir kaynağa bağlantı.
Eşzamanlılık sınırları ve geri doldurma için "gece pencereleri".

15) Test ve kalite

15. 1 Sözleşmeler ve olumsuz durumlar

JSON şemalarını, gerekli alanları, 'error _ code' kararlılığını doğrulayın.
Testler: sıra dışı, kopyalar, atlama olayları, sürüm çakışması, 429/5xx.

15. 2 Kaos/oyunlar

Enjeksiyonlar: ağ gecikmeleri, olayların %10-30 oranında düşmesi, yeniden sıralama.
Kriterler: Düzen/bütünlük korunur? Kayıp yok mu? SLO içinde gecikme?

16) Uygulama kontrol listesi

• Seçilen model (itme/çekme/melez) ve gerçeğin kaynağı.
• Artımlı deltalar: filigran veya imleç/belirteç.
• Pagination: sabit dereceli imleç/keyset.
• Idempotency-mağaza, anahtarlar ve TTL; tarafından dedup '(id, version/seq)'.
• ETag/If-Match ve çakışma politikası (LWW/server-wins/merge).
• Retry/backoff/jitter, saygı 'Retry-After'.
• Metrikler lag/backlog/duplicates/conflicts, panolar ve uyarılar.
• Mutabakat API + günlük mutabakatlar.
• Güvenlik: OAuth2/JWT, webhook imzaları, mTLS, PII politikaları.
• FinOps: parti + sıkıştırma, eşzamanlılık sınırları, çıkış kotaları.
• Test paketi: yeniden sıralama, kopyalar, kesintiler, geri doldurma.

17) Uygulama planı (3 yineleme)

1. MVP (1-2 hafta):

İmleç sayfalama, filigran deltaları, idempotent uppert, temel lag/backlog, rettry + backoff metrikleri.

2. Ölçek (2-3 hafta):

Tetik + yoklama-geri dönüş, HMAC imzaları, mutabakat, ETag/If-Match, gösterge panoları ve gecikme ile yanık uyarıları olarak Webhook'lar.

3. Pro (3-4 hafta):

Sıcak alanlar için CDC/streaming (Kafka/Debezium), otomatik doldurma, DR komut dosyaları, FinOps optimizasyonu (batch/brotley), gecikme ve raporlama için SLA.

18) Mini-SSS

Ne seçilir: filigran veya imleç?
İmleç/keyset yeniden sıralamaya ve ölçeğe karşı daha dirençlidir; Filigran başlatmak daha kolaydır, ancak çakışma ve deadup ekleyin.

Tam olarak bir kez gerekli mi?
Genel olarak pahalı. Uygulama - en az bir kez + idempotency; tam bir kez - sadece parasal etkiler için.

Çatışmalar nasıl en aza indirilir?
ETag/If-Match kullanın, tasarım alanlara göre birleşir, "gizli" yan etkilerden kaçının.

Toplam

Güvenilir senkronizasyon, artımlı deltalar + doğru sayfalama + idempotency ve sürüm kontrolü, gözlemlenebilirlik, ışıltılar ve ekonomik taşıma ile geliştirilmiştir. Doğru modeli seçin (push/pull/CDC), SLO'yu gecikmeye sabitleyin, çatışma politikaları ve kirli senaryo testleri uygulayın - ve veri alışverişiniz öngörülebilir, sürdürülebilir ve uygun maliyetli hale gelir.