Toʻgʻridan-toʻgʻri mos kelish

To’g «ridan-to’g» ri muvofiqlik nima

To’g’ridan-to’g’ri muvofiqlik (forward compatibility) - bu tizimning avvaliga mo’ljallanganidan ko’ra ko’proq yangi mijozlar yoki ma’lumotlar bilan to’g’ri ishlash qobiliyatidir. Oddiy: yangi mijoz kelganda eski server buzilmaydi; yangi xabarga duch kelganda eski isteʼmolchi tushmaydi.

Yangi tizim eski mijozlarni qo’llab-quvvatlaganda, forward javobgarlik yo’nalishi bilan ajralib turadi: biz protokollar va mijozlarni kelajakdagi kengayishlardan butun ekotizimni to’liq yangilamasdan «omon qolish» uchun loyihalashtiramiz.

Bazaviy prinsiplar

1. Tolerant reader & tolerant writer

Reader noma’lum maydonlarni/sarlavhalarni e’tiborsiz qoldiradi va to’g’ri fallback bilan yangi enum qiymatlariga ruxsat beradi.
Writer server qoʻllab-quvvatlanadigan (capabilities) deb eʼlon qilmagan hech narsani joʻnatmaydi.

2. Capability negotiation

Handshake bosqichida aniq imkoniyatlar almashinuvi (fich/versiya/media turlari). Mijoz oʻz xatti-harakatlarini server javobiga moslaydi.

3. Defolt degradatsiyasi

Yangi imkoniyatlar ixtiyoriy hisoblanadi: agar server/konsumer ularni qoʻllab-quvvatlamasa, stsenariy baribir foydali minimum (MGC) bilan yakunlanadi.

4. Barqaror yadro (MGC)

Eng kam kafolat kontrakti o’zgarmaydi; yangiliklar kengayish sifatida yashaydi.

5. Xato shartnomalari protokolning bir qismi sifatida

Oldindan aytib bo’ladigan kodlar/sabablar («fich qo’llab-quvvatlanmaydi», «media turi noma’lum») mijozga qo’llab-quvvatlanadigan rejimga avtomatik ravishda qaytish imkonini beradi.

6. Kutilmagan versiyalar

Major chiziqlar ajratilgan; minor kengaytmalar server/konsumerni yangilashni talab qilmaydi.

Bu ayniqsa muhim bo’lgan joyda

Uzoq muddatli integratsiyalashuvga ega ommaviy API (hamkorlar, mobil ilovalardagi SDK).
Ko’plab mustaqil konsumerlarga ega voqea platformalari.
Orqa tomonga qaraganda sekinroq yangilanadigan mobil mijozlar.
Edj/IoT, bu yerda qurilmalar parkining bir qismi kamdan-kam tikiladi.

Uslublar bo’yicha sotish patternlari

REST/HTTP

• ’Accept ’/moslamali mediatiplar (’ application/vnd. example. order+json; v=1; profile=risk`).
• ’Prefer: include =...’ ixtiyoriy bloklar uchun.
• Sarlavha’X-Capabilities: risk_score,item_details_v2'.

• Asosiy formatdagi soʻrovni yuboradi, agar server capability (OPTIONS/desc/lid-endpoint orqali) ni tasdiqlasa, kengaytiradi.
• ’415/406/501’ qoʻllaniladigan formatga/usulga avtomatik ravishda qaytadi.
• Serverning javobi: nomaʼlum parametrlar - eʼtiborsiz qoldirish; ortiqcha maydonlarga yo’l qo’yiladi; xato formati barqaror (’type/code/detail/trace _ id’).

gRPC / Protobuf

Barqaror servislar: yangi usullar/maydonlar - qo’shimcha; eski server xotirjam ravishda noma’lum so’rov maydonlarini e’tiborsiz qoldiradi.
Feature discovery:’GetCapabilities ()’usuli fich/limitlar roʻyxatini qaytaradi. Agar server uni eʼlon qilmasa, mijoz «v2-usul» ni chaqirmaydi.
Striming: xabarlarni minimal toʻplash tartibini belgilang; Yangi «ramkalar» ni eski mijoz e’tiborsiz qoldiradigan kengaytmalar/turlar bilan belgilang.

GraphQL

Forward-friendly: serverda yangi maydonlar/turlar paydo bo’ladi - eski mijozlar ularni so’ramaydi.
Taxmin qilish taqiqlangan: mijoz sxemani (introspektsiya/kodogen) ushlab turishi va noma’lum direktivalarni/o’zgaruvchilarni yubormasligi kerak.
Tanazzul: agar server kastom direktivasini/feature bilmasa, mijoz soʻrovni usiz tuzadi.

Event-driven (Kafka/NATS/Pulsar, Avro/JSON/Proto)

Ro’yxatdagi sxemaning FORWARD mosligi: eski konsumerlar yangi sxema bilan yozilgan xabarlarni o’qishlari mumkin.
Qo’shimchalar va defoltlar: yangi prodyuserlar eski konsumerlarni buzmaydi.
Core vs Enriched: yadro o’zgarishsiz qolmoqda, yangi ma’lumotlar’.enriched’yoki’opsion’sifatida e’lon qilinadi.

Loyihalash amaliyoti

1. Eng kam so’rov shartnomasi (MGC)

Operatsiya barcha serverlar ko’p yillar davomida qo’llab-quvvatlaydigan «tor bo’yin» ga ega bo’lishi kerak.

2. Kontrakt darajasidagi fich-bayroqlar

«risk _ score», «pricing _ v2», «strong _ idempotency» kabi imkoniyatlarni tavsiflang. Mijoz ularni aniq o’z ichiga oladi.

3. «Qoʻllab-quvvatlanmaydi» uchun aniq xato kodlari

HTTP: `501 Not Implemented`, `415 Unsupported Media Type`, детальные `problem+json`.
gRPC: `UNIMPLEMENTED`/`FAILED_PRECONDITION`.
Events: DLQ yo’nalishi s’reason = unsupported _ feature’.

4. Tartibga/toʻliq roʻyxatlarga tayanmaslik

Mijoz yangi enum qiymatlariga, yangi maydonlarning yoʻqligiga va «qoʻshimcha» xususiyatlarga tayyor boʻlishi kerak.

5. Barqaror identifikatorlar va formatlar

Liniya ichidagi partizanlashtirish ID/kalitlari formatini oʻzgartirmang - bu oʻquvchilar tomonidagi forwardni buzadi.

6. «Mashinada o’qiladigan» hujjatlar

OpenAPI/AsyncAPI/Proto descriptors/GraphQL SDL. Mijozlar qo’llab-quvvatlashni tekshirishlari mumkin.

Forward mosligini sinash

Schema-diff FORWARD/FULL rejimida: yangi sxema eski isteʼmolchini/serverni tasdiqlaydi.
Mijozning shartnomaviy testlari: yangi mijoz eski serverga qarshi bajariladi.
Golden requests: «yangi» soʻrovlar toʻplami «eski» server orqali haydaladi; tanqidiy xatolarsiz tanazzulga uchrashi kutilmoqda.
Chaos/latency: taymaut/retraylarni tekshirish - yangi mijoz eski serverning eng yomon SLAsidan toʻgʻri omon qolishi kerak.
Canary: yangi mijozlarning bir qismi oldingi server versiyasi bilan ishlaydi - xatolar/degradatsiyalar telemetriyasini yig’ish.

Kuzatuvchanlik va operatsion metriklar

Qo’llab-quvvatlanmaydigan so’rovlar/xabarlar ulushi.
Mijozlar versiyalari bo’yicha taqsimlash (User-Agent/meta ma’lumotlar/claims).
’UNIMPLEMENTED/501/415’ xatolari va’unsupported _ feature’bilan DLQ yo’nalishlari.
Tanazzul vaqti: MGC uchun p95/p99 «kengaytirilgan» javobga qarshi.

Sxemalar reyestridagi moslik rejimlari

FORWARD: Yangi yozuv eski o’quvchiga mos keladi (defoltlar, ixtiyoriylik kerak).
FULL: и FORWARD, и BACKWARD; ochiq shartnomalar uchun qulay.
Tavsiya: voqealar uchun - prodyuserda BACKWARD va konsumerda FORWARD (tolerant reader orqali), tashqi API uchun - FULL.

Namunalar

REST (capabilities + degradatsiya)

1. Mijoz’GET/meta/capabilities’→’{"risk_score": false,’price_v2": true}’ni yaratadi.
2. ’POST/orders’ ga asosiy maydonlarni yuboradi;’risk _ score’soʻramaydi, chunki server buni bilmaydi.
3. Agar’Prefer: include = risk _ score’tasodifan yuborilsa, server’risk _ score’(yoki’Preference-Applied: none’) maydonisiz 200 javob beradi - mijoz tushmaydi.

gRPC (discovery)

’GetCapabilities ()’ usullar roʻyxatini qaytardi. Mijoz’CaptureV2’ga qoʻngʻiroq qilmaydi, agar u mavjud boʻlmasa, uning oʻrniga’Capture’dan foydalanadi va kirish maʼlumotlarini qoʻllab-quvvatlanadigan koʻrinishga aylantiradi.

Events (reyestrdagi FORWARD)

Prodyuser’risk _ score’(nullable bilan defolt) maydonini qoʻshdi. Eski konsumer uni e’tiborsiz qoldiradi; uning mantig’i faqat yadroning barqaror maydonlaridan foydalanadi.

Antipatternlar

Qattiq mijoz: javobni whitelist maydonlariga filtrlaydi va notanish xususiyatga tushadi.
Notoʻgʻri fichlar: mijoz capabilities tekshirmasdan yangi parametrni joʻnatishni boshlaydi.
Eski serverlar/konsumerlar yangi soʻrovlar/xabarlarni tushunmay qolmoqda.
Enum (default boʻlmagan switch) toʻliq roʻyxati haqida tikilgan taxminlar.
Logotip oqim nazorati sifatida: shartnoma kodlari oʻrniga xato satrlarini parsing.

Joriy etish chek-varaqasi

• MGC tomonidan aniqlangan; yangi imkoniyatlar opsion sifatida belgilangan.
• Capability negotiation (endpoint/meta maʼlumotlar/handshake) tasvirlangan va amalga oshirilgan.
• Mijozlar notanish maydonlarga e’tibor bermaydi va yangi enum (fallback) ni to’g’ri qayta ishlaydi.
• Xato shartnomalari oldindan aytib bo’lmaydigan tarzda «qo’llab-quvvatlanmaydi» (HTTP/gRPC/Event).
• Sxemalar reyestri tegishli artefaktlar uchun FORWARD/FULL sozlangan.
• Avtostestlar: schema-diff (FORWARD), mijozning eski serverga qarshi shartnomaviy testlari, canary.
• Metrika: mijozning versiyasi, nuqsoni, tanazzullar ulushi, p95 MGC.
• Hujjatlar/SDK fich ro’yxati va degradatsiya misollarini e’lon qiladi.

FAQ

Forward amalda backwarddan qanday farq qiladi?
Backward: yangi server eski mijozlarni buzmaydi. Forward: eski server yangi mijozlardan (yoki eski konsumer - yangi xabarlardan) uzilmaydi. Ideal holda siz full ga erishasiz.

Har doim capabilities kiritish kerakmi?
Agar siz faol evolyutsiyani sinxron relizlarsiz kutayotgan bo’lsangiz, ha. Bu o’nlab major-liniyalarni saqlashdan arzonroq.

Xavfsizlik haqida nima deyish mumkin?
Yangi fichlar alohida scopes/claims talab qilishi kerak. Agar server ularni qoʻllab-quvvatlamasa, mijoz xavfsizlikni pasaytirmasligi kerak, balki fichidan voz kechishi kerak.

Server yordamini «taxmin qilish» mumkinmi?
Nomaqbul. Aniq so’rash (capabilities) yoki media/sxemaga qarash yaxshiroqdir.

Jami

To’g’ridan-to’g’ri muvofiqlik - bu imkoniyatlar to’g’risida kelishib olish va xavfsiz ravishda tanazzulga uchrashdir. Barqaror yadro, capability negotiation, qo’shimcha kengaytmalar va oldindan aytib bo’ladigan xatolar yangi mijozlar va ma’lumotlar bilan eski serverlar va iste’molchilar bilan - ommaviy relizlar va tungi migratsiyalarsiz muloqot qilish imkonini beradi.