Idempotency — bir amal bir marta yoki bir necha marta bajarilganda tizimning yakuniy holati bir xil bo‘lib qolishini ifodalovchi xususiyat. Bu tushuncha matematika, HTTP, database, distributed system va deployment jarayonlarida keng qo‘llanadi.
Idempotent amal takroriy chaqirilganda yangi va kutilmagan o‘zgarish yaratmaydi. Masalan, “foydalanuvchi holatini faol qilish” amali bir marta yoki besh marta bajarilsa ham yakuniy holat active = true bo‘lib qoladi.
Asosiy mazmun
Idempotency quyidagi ikki holatni taqqoslaydi:
amal bir marta bajarildi
va
amal bir necha marta bajarildi
Agar tizimning muhim yakuniy holati bir xil bo‘lsa, amal idempotent hisoblanadi.
Bu yerda “bir xil” deganda faqat qaytarilgan HTTP status emas, balki database, file, queue, balans yoki boshqa tashqi holat tushuniladi.
Oddiy misol
Quyidagi amal idempotent:
user.status = "active"
U takrorlansa ham holat o‘zgarmaydi.
Quyidagi amal esa odatda idempotent emas:
user.balance += 100
Har takrorlash balansga yana 100 qo‘shadi.
Matematik ta’rif
Matematik funksiyada idempotency:
f(f(x)) = f(x)
ko‘rinishida ifodalanadi.
Masalan, modulning absolute qiymatini olish:
abs(abs(x)) = abs(x)
Bu natija takroriy bajarilishda o‘zgarmaydi.
HTTP metodlar
HTTP specification’da ayrim metodlar idempotent deb qaraladi.
GET
Resource holatini o‘qiydi va odatda serverdagi asosiy holatni o‘zgartirmaydi.
GET /users/15
Takroriy so‘rov bir xil ma’noga ega.
PUT
Resource’ni berilgan to‘liq holatga keltiradi.
PUT /users/15
{
"name": "Farrukh",
"active": true
}
Bir xil body bilan qayta yuborilganda yakuniy resource holati o‘zgarmaydi.
DELETE
Resource birinchi so‘rovda o‘chadi. Keyingi so‘rov 404 qaytarishi mumkin, ammo resource baribir mavjud emas.
Shuning uchun yakuniy server holati bir xil.
POST
POST odatda idempotent emas.
POST /orders
har chaqiriqda yangi order yaratishi mumkin.
Biroq idempotency key orqali POST ham amaliy jihatdan idempotent qilinishi mumkin.
Idempotency key
Client har muhim operatsiyaga noyob kalit yuboradi.
Idempotency-Key: 8a4f...
- kalitni qabul qiladi;
- oldin ishlatilganini tekshiradi;
- yangi bo‘lsa amalni bajaradi;
- natijani kalit bilan saqlaydi;
- qayta kelganda eski natijani qaytaradi.
Bu to‘lov, buyurtma va boshqa takrorlanmas operatsiyalar uchun muhim.
To‘lov tizimi
Network timeout sabab client server javobini olmay qolishi mumkin.
Client payment requestni qayta yuboradi.
Idempotency bo‘lmasa bir foydalanuvchidan ikki marta pul yechilishi mumkin.
To‘lov amali quyidagi identifikatorlardan foydalanishi mumkin:
- idempotency key;
- merchant transaction ID;
- order ID;
- payment intent ID.
Server bitta business operationni faqat bir marta amalga oshiradi.
Retry bilan bog‘liqligi
Distributed tizimda vaqtinchalik xatolar uchun retry keng qo‘llanadi.
Retry sabab bir request:
- aslida bajarilgan;
- javobi yo‘qolgan;
- yana yuborilgan
bo‘lishi mumkin.
Idempotent operation retry’ni xavfsizroq qiladi.
Retry mavjudligi idempotencyni avtomatik bermaydi. Operationning o‘zi duplicate ta’sirni oldini olishi kerak.
Database darajasi
Database idempotencyni bir nechta usul bilan qo‘llab-quvvatlaydi.
Unique constraint
Transaction ID uchun unique constraint duplicate yozuvni bloklaydi.
UNIQUE(transaction_id)
Upsert
Record mavjud bo‘lsa update, yo‘q bo‘lsa insert qilinadi.
Bir xil key bilan takroriy yozuv yangi duplicate yaratmaydi.
Conditional update
Holat faqat kerakli oldingi state mavjud bo‘lsa o‘zgaradi.
UPDATE payments
SET status = 'paid'
WHERE id = ? AND status = 'pending'
Transaction log
Bajarilgan command IDsi alohida jadvalda saqlanadi.
Message queue
Message broker bir xabarni bir necha marta yetkazishi mumkin.
Bu at-least-once delivery modelida odatiy.
- message IDni saqlaydi;
- duplicate xabarni taniydi;
- business operationni qayta bajarmaydi.
Faqat brokerga ishonish yetarli emas, chunki consumer amalni bajarib, acknowledgement yuborishdan oldin crash qilishi mumkin.
Exactly-once tushunchasi
“Exactly once” ko‘pincha marketing yoki cheklangan boundary ichidagi kafolat.
Haqiqiy distributed system’da:
mavjud.
Amaliy yondashuv ko‘pincha at-least-once delivery va idempotent consumerdan iborat.
Deployment
Infrastructure automation ham idempotent bo‘lishi kerak.
Masalan:
package o‘rnatilgan bo‘lsa qayta o‘rnatilmaydi
directory mavjud bo‘lsa saqlanadi
config faqat farq bo‘lsa yangilanadi
service kerakli holatga keltiriladi
Script har ishga tushganda “yana qo‘shish” o‘rniga “kerakli holatni ta’minlash”ga intiladi.
Fayl operatsiyalari
Quyidagi amal idempotent:
fayl mazmunini aynan berilgan qiymatga almashtirish
Quyidagi amal idempotent emas:
har safar fayl oxiriga bir satr qo‘shish
Takroriy bajarishda duplicate satrlar paydo bo‘ladi.
Vaqt va tashqi ta’sir
Amal database holati bo‘yicha idempotent bo‘lsa ham:
takrorlanishi mumkin.
Shuning uchun idempotency boundary aniq belgilanadi.
To‘lov bir marta amalga oshib, email ikki marta yuborilishi ham foydalanuvchi uchun muammo bo‘lishi mumkin.
Idempotency oynasi
Server idempotency key natijasini cheksiz saqlamasligi mumkin.
Masalan:
- 24 soat;
- 7 kun;
- transaction muddati.
Retention tugagach bir xil key yangi deb qabul qilinishi mumkin.
Bu siyosat API hujjatida ko‘rsatiladi.
Payload mosligi
Bir xil idempotency key boshqa payload bilan yuborilsa server xato qaytarishi kerak.
Aks holda client qaysi amal bajarilganini bilmaydi.
Server kalit bilan birga request hash yoki muhim parameterlarni saqlashi mumkin.
Bog‘liq tushunchalar
Idempotent operation, Retry, Idempotency key, Duplicate request, At-least-once delivery, Exactly-once, Upsert, Unique constraint, Distributed system, Transaction