Retention Policy — data, log yoki backup qancha vaqt va qaysi shartgacha saqlanishini belgilaydigan qoidalar majmui. U taqsimlangan messaging, event-driven arxitektura yoki ma’lumotlar bazasi ichki ishlashida aniq vazifani bajaradi. Kafolatlar implementatsiya va konfiguratsiyaga bog‘liq; atamaning o‘zi durability, ordering yoki consistency darajasini avtomatik belgilamaydi.
Mazmuni va vazifasi
Retention vaqt, hajm, versiya soni yoki huquqiy talabga asoslanadi. Tizim segment yoki obyektni eligibility shartiga yetgach o‘chiradi, arxivlaydi yoxud arzonroq qatlamga ko‘chiradi.
Retention Policy alohida modul sifatida ko‘rinsa ham, uning natijasi qo‘shni qatlamlar bilan belgilanadi. Input qabul qilinishi, state persistent bo‘lishi va consumer yoki query natijasida ko‘rinishi turli vaqt nuqtalari bo‘lishi mumkin.
Ishlash mexanizmi
TTL ko‘pincha bitta yozuvning amal qilish muddatidir; retention esa butun dataset lifecycle’ini, delete jarayonini va istisnolarni boshqaradi. Log compaction keyning oxirgi holatini saqlashi mumkin, time retention esa yoshiga qarab o‘chiradi.
Retention Policy uchun scope va ownership yozma ravishda belgilanadi. Producer, broker, database yoki consumer qaysi metadata’ni yaratishi, kim uni o‘zgartira olishi va qaysi acknowledgement durable holatni anglatishi aniq bo‘lsa retry paytidagi noaniqlik kamayadi. Retention Policy uchun mas’ul komponent health signalidan tashqari, o‘zi himoya qiladigan invariant buzilmaganini ham davriy ravishda tekshiradi.
Retention Policyga bog‘liq tashqi dependency sekinlashganda timeoutlar bir-biriga mos bo‘lishi kerak. Yuqori qatlamdagi deadline pastki qatlam retrylaridan qisqa bo‘lsa, bekor qilingan request orqa fonda resource sarflashda davom etishi mumkin. Cancellation propagation, bounded queue va circuit breaker nazoratli degradatsiya yaratishga yordam beradi.
Chegaralari
Legal hold, audit, replica lag va offline consumer hisobga olinmasa kerakli tarix erta yo‘qoladi. Cheksiz retention esa xarajat, qidiruv va maxfiylik xavfini oshiradi.
Retention Policy retention va cleanup siyosatiga bog‘liq. Log, tombstone, schema yoki transaction metadata erta o‘chirilsa replay va recovery buziladi; cheksiz saqlansa xarajat hamda maxfiylik xavfi ortadi.
Correctness, latency, throughput va storage xarajati birga tanlanadi. Tezroq acknowledgement yoki ko‘proq parallelism kiritilganda buffer, ordering va recovery talablari o‘zgaradi. Shu sabab Retention Policy bo‘yicha qaror faqat nominal benchmarkga tayanmaydi.
Tekshirish
Retention Policy diagnostikasida request yoki event identifier bo‘yicha kirish, qaror va tashqi natija bir vaqt chizig‘iga qo‘yiladi. Physical clocklar mos kelmasa sequence, offset, transaction ID yoki commit index asosiy dalil bo‘ladi.
Retention Policyga oid metadata asosiy payloaddan kichik bo‘lsa ham muhim. Version, timestamp, key, checksum va provenance yo‘qolsa consumer taxminiy default bilan noto‘g‘ri qaror qilishi mumkin; noma’lum variant quarantine qilinadi.
Retention Policyda audit faqat kim o‘zgartirganini emas, oldingi va yangi qiymat, sabab, approval hamda amal qilish muddatini qayd etadi. Emergency override avtomatik expiryga ega bo‘lmasa, vaqtinchalik xavfli rejim yashirin defaultga aylanib qolishi mumkin.
Retention Policy bilan bog‘liq qarorlar data hajmi o‘sganda qayta baholanadi. Kichik datasetda arzon ko‘ringan full scan, broadcast yoki in-memory state production masshtabida disk spill va network saturation keltirishi mumkin. Growth threshold uchun alert va migration rejasi oldindan belgilanib, favqulodda paytda yangi arxitektura o‘ylab topishga ehtiyoj kamaytiriladi.
Retention Policy o‘zgartirilgach normal oqim bilan birga malformed input, timeout, duplicate, restart va partial failure tekshiriladi. Qabul qilingan cheklovlar hujjatlashtiriladi; boshqa workload yoki platformaga ko‘r-ko‘rona ko‘chirilmaydi.
Bog‘liq tushunchalar
data lifecycle, TTL, log compaction, archival storage, legal hold, garbage collection