Voqealarni duplikatsiya qilish

1) Nega deduplikatsiya kerak

• invariantlar buziladi (ikki marta hisobdan chiqarish, takroran email/SMS, «ikki marta yaratilgan» buyurtma);
• xarajatlar o’sib bormoqda (takroriy yozuvlar/qayta ishlash);
• tahlillar buzib ko’rsatiladi.

Deduplikatsiyadan ko’zlangan maqsad ko’pincha idempotentlik bilan birga transportni takrorlashda bir marta kuzatiladigan samarani ta’minlashdan iborat.

2) Deduplikatsiyani qayerda joylashtirish (darajalar)

1. Edge/API-shlyuz -’Idempotency-Keu’bo’yicha aniq dubllarni kesib tashlaymiz/tana + imzo.
2. Broker/oqim - kalit/sekvens bo’yicha mantiqiy deduplikatsiya, sog’inishda coalescing (kam hollarda - qiymati tufayli).
3. Hodisa qabul qiluvchi (consumer) - asosiy joy: Inbox/kalit jadvali/kesh.
4. Sink (BD/kesh) - noyob kalitlar/UPSERT/versiyalar/kompaksiya.
5. ETL/tahlil - vaqt oynasi va ustunli storlarda kalit bo’yicha dedup.

Qoida: iloji boricha erta, lekin noto’g "ri ishlanmalar qiymati va replay zarurligini hisobga olgan holda.

3) Deduplikatsiya kalitlari

3. 1 Tabiiy (afzalroq)

`payment_id`, `order_id`, `saga_id#step`, `aggregate_id#seq`.
Barqarorlik va ma’noni kafolatlaydi.

3. 2 Tarkibiy

`(tenant_id, type, external_id, version)` или `(user_id, event_ts_truncated, payload_hash)`.

3. 3 Fingerprint

Determinizatsiya qilingan maydonlar kichik turkumining xeshi (tartib/registrlarni normallashtirish),’HMAC (secret, payload)’opsionaldir.

3. 4 Ketma-ketlik/versiya

Monotonli’seq’per aggregate (optimistik blokirovka/versiya).

Anti-pattern: «random UUID» biznes mohiyati bilan aloqasiz - dedup mumkin emas.

4) Vaqtinchalik derazalar va tartib

Deduplikatsiya oynasi - voqea takroran kelishi mumkin bo’lgan davr (odatda 24-72 soat; moliya uchun - uzoqroq).
Out-of-order: kechikishga yo’l qo’yamiz (lateness). Oqimli freymvorklarda - event time + watermarks.
Sliding/Fix-window dedup: "Oxirgi N daqiqada kalitni koʻrdingizmi? ».
Sequence-aware: agar’seq’oxirgi ishlov ≤ - dubl/takrorlash.

5) Ma’lumotlar va amalga oshirish tuzilmasi

5. 1 Aniq hisob (exact)

Redis SET/STRING + TTL:’SETNX key 1 EX 86400’→ «birinchi marta - qayta ishlaymiz, aks holda - SKIP».
LRU/LFU kesh (in-proc): tezkor, lekin volatile → faqat birinchi to’siq sifatida yaxshiroqdir.
SQL noyob indekslar + UPSERT: «qoʻyish yoki yangilash» (idempotent effekt).

5. 2 Yaqin tuzilmalar (probabilistic)

Bloom/Cuckoo filter: arzon xotira, yolg’on xatolar (false positive). Aniq «shovqinli» drop (masalan, telemetriya) uchun mos keladi, moliya/buyurtmalar uchun emas.
Count-Min Sketch: «issiq» dubllardan himoya qilish uchun chastotalarni baholash.

5. 3 Oqim holatlari

Kafka Streams/Flink: keyed state store c TTL, derazadagi kalit bo’yicha dedup; checkpoint/restore.
Watermark + allowed lateness: kechiktirilgan voqealar oynasini boshqaradi.

6) Tranzaksion patternlar

6. 1 Inbox (kirish jadvali)

pseudo
BEGIN;
ins = INSERT INTO inbox(id, received_at) ON CONFLICT DO NOTHING;
IF ins_not_inserted THEN RETURN cached_result;
result = handle(event);
UPSERT sink with result; -- idempotent sync
UPDATE inbox SET status='done', result_hash=... WHERE id=...;
COMMIT;

Takrorlash yozuvni koʻradi va effektni takrorlamaydi.

6. 2 Outbox

Bitta tranzaksiyadagi biznes-yozuv va voqea → nashriyotchi brokerga beradi. Iste’molchidan dublni yo’q qilmaydi, lekin «teshiklarni» yo’q qiladi.

6. 3 Noyob indekslar/UPSERT

sql
INSERT INTO payments(id, status, amount)
VALUES ($1, $2, $3)
ON CONFLICT (id) DO NOTHING; -- "create once"

sql
UPDATE orders
SET status = $new, version = version + 1
WHERE id=$id AND version = $expected; -- optimistic blocking

6. 4 Agregatlarni versiyalash

Agar’event’boʻlsa, hodisa qoʻllaniladi. version = aggregate. version + 1`. Aks holda - dubl/takrorlash/mojaro.

7) Dedup va brokerlar/strimlar

7. 1 Kafka

Idempotent Producer kirish joyidagi dubllarni kamaytiradi.
Transactions + chiqish yozuvlarini atomik ravishda birlashtirishga imkon beradi.
Compaction: oxirgi per key - post-faktum dedup/koalitesing qiymatini saqlaydi (toʻlovlar uchun emas).
Consumer-side: state store/Redis/DB oynaning kalitlari uchun.

7. 2 NATS / JetStream

Ack/tahrirlash → at-least-once. Isteʼmolchidagi dedup (Inbox/Redis).
JetStream sequence/durabot takrorlashni osonlashtiradi.

7. 3 Navbatlar (Rabbit/SQS)

Visibility timeout + qayta yetkazib berish → kalit + dedup stor kerak.
SQS FIFO’MessageGroupId ’/’ DeduplicationId’bilan yordam beradi, ammo TTL oynalari provayder tomonidan cheklangan - agar biznes talab qilsa, kalitlarni uzoqroq saqlang.

8) Omborlar va tahlillar

8. 1 ClickHouse/BigQuery

’ORDER BY key, ts’ i’argMax ’/’ anyLast’sharti bilan.

sql
SELECT key,
anyLast(value) AS v
FROM t
WHERE ts >= now() - INTERVAL 1 DAY
GROUP BY key;

Yoki «noyob» hodisalarning materiallashtirilgan qatlami (merj).

8. 2 Logi/telemetriya

Masalan, approximate-dedup (Bloom) ingest → tarmoq/diskni tejaymiz.

9) Qayta ishlash, repley va bekfill

Dedup kalitlar repleyni boshdan kechirishi kerak (TTL ≥ repleyning oynasi).
Backfill uchun onlayn oynaga xalaqit bermaslik uchun’key #source = batch2025’versiyali kalitlar maydonidan yoki alohida «olxoʻri» dan foydalaning.
Natija artefaktlarini (hash/versiya) saqlang - bu «fast-skip» ni takrorlashda tezlashtiradi.

10) Metrika va kuzatish

’dedup _ hit _ total ’/’ dedup _ hit _ rate’ - ushlangan dubllar ulushi.
Ehtimollik filtrlari uchun’dedup _ fp _ rate’.
’window _ size _ seconds’ haqiqiy (telemetry late arrivals boʻyicha).
`inbox_conflict_total`, `upsert_conflict_total`.
`replayed_events_total`, `skipped_by_inbox_total`.
tenant/key/type profillari: eng koʻp dubllar qayerda va nima uchun.

Логи: `message_id`, `idempotency_key`, `seq`, `window_id`, `action=process|skip`.

11) Xavfsizlik va maxfiylik

PII’ni kalitga qo’ymang; xesh/taxalluslardan foydalaning.
Izni imzolash uchun - HMAC (secret, canonical_payload).
Kalitlarni saqlash muddatini GDPR retenshn bilan kelishib oling.

12) Unumdorlik va qiymat

In-proc LRU ≪ Redis ≪ SQL operatsiya uchun yashirin/qiymat bo’yicha.
Redis: arzon va tez, lekin kalitlar va TTL hajmini hisobga oling; ’tenant/hash’.
SQL: p99 uchun qimmat, ammo kuchli kafolatlar va auditoriyani beradi.
Probilistik filtrlar: juda arzon, ammo FP mumkin - «ortiqcha SKIP» tanqidiy bo’lmagan joylarda qo’llang.

13) Anti-patternlar

«Bizda Kafka exactly-once - kalit kerak emas». Ko’k/biznes qatlamida kerak.
Kalit uchun TTL juda qisqa → reple/kechikish dubl keltiradi.
Global yagona dedup stor → hotspot va SPOF; tenant/kalitda shardalanmagan.
Dedup faqat xotirada - jarayonning yoʻqolishi = dubl toʻlqini.
Pul/buyurtmalar uchun Bloom - false positive qonuniy operatsiyadan mahrum qiladi.
Kelishilmagan payload kanonizatsiyasi - ma’nosi bir xil bo’lgan xabarlarning xeshlari.
Out-of-order - kech hodisalarni eʼtiborsiz qoldirish xato bilan belgilanadi.

14) Joriy etish chek-varaqasi

• Tabiiy kalitni (yoki tarkibiy/izni) aniqlang.
• Dedup oynasi va’lateness’siyosatini oʻrnating.
• Darajani tanlang: edge, consumer, sink; shardalashni nazarda tuting.
• Inbox/UPSERT ni amalga oshiring; oqimlar uchun - keyed state + TTL.
• Agar approximate-to’siq kerak bo’lsa - Bloom/Cuckoo (faqat tanqidiy bo’lmagan domenlar uchun).
• Moslashuvchanlikni moslash (TTL ≥ replay/backfill oynasi).
• ’dedup _ hit _ rate’metrikasi, mojarolar va derazalar laglari; per-tenant dashbordlari.
• Game Day: taymaut/retray, replay, out-of-order, yiqilish.
• Payload kanonizatsiyasini va kalitlarni versiyalashni hujjatlashtiring.
• «Issiq kalitlar» va uzun derazalarda yuklash testlarini o’tkazing.

15) Konfiguratsiya/kod namunalari

15. 1 Redis SETNX + TTL (to’siq)

lua
-- KEYS[1] = "dedup:{tenant}:{key}"
-- ARGV[1] = ttl_seconds local ok = redis. call("SET", KEYS[1], "1", "NX", "EX", ARGV[1])
if ok then return "PROCESS"
else return "SKIP"
end

15. 2 PostgreSQL Inbox

sql
CREATE TABLE inbox (
id text PRIMARY KEY,
received_at timestamptz default now(),
status text default 'received',
result_hash text
);
-- In the handler: INSERT... ON CONFLICT DO NOTHING -> check, then UPSERT in blue.

15. 3 Kafka Streams (derazadagi dedup)

java var deduped = input
.selectKey((k,v) -> v.idempotencyKey())
.groupByKey()
.windowedBy(TimeWindows. ofSizeWithNoGrace(Duration. ofHours(24)))
.reduce((oldV,newV) -> oldV)   // first wins
.toStream()
.map((wKey,val) -> KeyValue. pair(wKey. key(), val));

15. 4 Flink (keyed state + TTL, psevdo)

java
ValueState<Boolean> seen;
env. enableCheckpointing(10000);
onEvent(e):
if (!seen.value()) { process(e); seen. update(true); }

15. 5 NGINX/API-shlyuz (Idempotency-Key on edge)

nginx map $http_idempotency_key $idkey { default ""; }
Proxy the key to the backend; backend solves deadup (Inbox/Redis).

16) FAQ

Q: Nima tanlash kerak: dedup yoki sof idempotentlik?
A: Odatda ikkalasi ham: dedup - tezkor «filtr» (tejash), idempotentlik - to’g’ri ta’sirning kafolati.

Q: Qanday TTL qo’yish kerak?
A: qayta yetkazib berish mumkin bo’lgan maksimal vaqt + zaxira ≥. Tipik 24-72h; moliya va kechiktirilgan vazifalar uchun - kunlar/haftalar.

Q: Kechki voqealarni qanday hal qilish kerak?
A:’allowed lateness’va’late _ event’signalizatsiyasini sozlang; kech - alohida shoxobcha orqali (recompute/skip).

Q: Telemetriyaning butun oqimini deuplikatsiya qilish mumkinmi?
A: Ha, edge’dagi approximate-filtrlar bilan, lekin FP’ni hisobga oling va tanqidiy biznes effektlariga tatbiq etmang.

Q: Dedup bekfilga xalaqit beradimi?
A: Kalitlar maydonini ajrating (’key #batch2025’) yoki bekfill vaqtidagi to’siqni o’chiring; TTL faqat onlayn oynalarni qamrab olishi kerak.

17) Yakunlar

Deduplikatsiya - bu kompozitsiya: to’g’ri kalit, oyna va holat tuzilishi + tranzaksion patternlar (Inbox/Outbox/UPSERT) va tartib va kechikkan voqealar bilan ongli ravishda ishlash. To’siqlarni eng arzon joyga qo’ying, sinklarda o’zgaruvchanlikni ta’minlang,’dedup _ hit _ rate’ni o’lchang va reple/fayllarni sinab ko’ring, shunda siz «samarali exactly-once» ga ega bo’lasiz.