Nima uchun API barqarorligini kuzatish muhim?

API - shartnoma. Uning har qanday beqarorligi konversiyalarning pasayishiga, muvaffaqiyatsizliklarning oshishiga, to’lovlarning buzilishiga va issiq fikslarning xarajatlariga aylanadi. Barqarorlik - bu «hech narsani o’zgartirmaslik» emas, balki aniq kafolatlar va o’lchovli SLO bilan boshqariladigan o’zgarishlar. Quyida - relizlar, eng yuqori yuklar va hamkorlik integratsiyalarini boshdan kechiradigan barqaror APIlarni qanday qurish kerak.

1) «API barqarorligi» nima va nima uchun pul

Bashoratlilik: bir xil harakat → bir xil natija (bir xil kontekstda).

Moslik: yangi versiyalar mavjud mijozlarni buzmaydi.

Foydalanish va ishlash: past p95/p99 latentlik, minimal xato.

O’zgarishlarni boshqarish: rejalashtirilayotgan deprekeytlar «kutilmagan hodisalarsiz».

Biznes effekti: kamroq hodisalar, yuqori konvertatsiya, tezroq Time-to-Market (kamroq kelishuv va qo’lda sotfiks).

2) Kontrakt eng avvalo

Spetsifikatsiyasi: OpenAPI/AsyncAPI + yagona haqiqat manbai (repo + CI-tekshirish).

Qat’iy kelishuvlar: turlari, maydonlarning majburiyligi, xato kodlari, semantika; «jim» o’zgarishlarni taqiqlash.

Moslik darajalari:

Backwards compatible (ixtiyoriy maydonlarni, yangi enum qiymatlarini, yangi endpointlarni qoʻshish).
Breaking (olib tashlash/qayta nomlash, turlarni/semantikani o’zgartirish, validatsiyani kuchaytirish).
Shartnoma testlari: Pact/Swagger-based - provayder, agar u e’lon qilingan iste’molchi umidlarini buzsa, chiqib keta olmaydi.

3) SLI/SLO va noto’g "ri budjet

SLI: muvaffaqiyatli so’rovlar ulushi, p95/p99 latency, kodlar bo’yicha 5xx/4xx ulushi, idempotent takrorlar ulushi.

SLO (misol): Muvaffaqiyat ≥ 99. 95%, p95 ≤ 100 ms (read) va ≤ 300 ms (write), 5xx ≤ 0. 05%.

Error Budget: o’zgartirish/tajriba o’tkazishga ruxsat berish; tugaganda - barqarorlikka e’tibor qaratish va xavfli relizlarni taqiqlash.

4) Idempotentlik, retraj va tranzaksiyalar

Write-operatsiyalar uchun idempotent kalitlar (to’lovlar, stavkalar, buyurtmalar): takrorlash → xuddi shunday natija.

Takrorlanadigan namunalar: eksponensial kechikish va jitter bilan retry, server tomonida deduplikatsiya.

Idempotent adolat:’lock → outcome → settle’(pul operatsiyalari) aniq TTL va maqomlarga ega.

Xato semantikasi: mojarolar uchun 409/422, chegaralar uchun 429, degradatsiyalar uchun 503/504, aniq’reason _ code’.

5) Sxemalarni versionlashtirish va evolyutsiyasi

Strategiya: SDK uchun SemVer, URL/API uchun sarlavhalar (’/v1’, ’/v2’yoki’Accept: application/vnd. api+json; v=2`).

Muvofiqlik qoidalari:

Maydonlarni ixtiyoriy deb qoʻshing; mavjud maydonning turini hech qachon oʻzgartirmang.
Enumni kengaytiring, qayta belgilamang; mijozlar noma’lum qiymatlarni e’tiborsiz qoldirishi shart.
Breaking-o’zgarishlar uchun - shartnomaning yangi versiyasi, de-fakto «fork».
Deprecation policy: e’lon → qo’llab-quvvatlash davri (masalan, 6-12 oy) → bosqichma-bosqich o’chirish; maqom sahifasi va changelog.

6) Hodisalarni kuzatish va boshqarish

Metrika (Prometheus/OTel): muvaffaqiyat, latency (p50/p95/p99), RPS, saturation (CPU/heap), rate xatolari.

Treysing: correlation id (masalan,’X-Request-ID’), span’s po hops (gateway → BFF → servis).

Loglar: strukturalangan, PII-safe, «tenant», «version», «client _ id», «idempotency _ key».

Alyorta: SLO-buzilishi, 5xx/429 ko’tarilishi, p99 o’sishi, dedloklarning «taym-qutilari».

Hodisalar: pleybuk, aloqa kanallari, action items bilan postmortem va agar kerak bo’lsa, SLO/chegaralarni o’zgartirish.

7) Unumdorlik va barqarorlik

Rate limiting / quotas: per-client/per-token; 429 s’Retry-After’ning halol javoblari.

Circuit breaker/bulkhead: qaramliklarni izolyatsiya qilish, lokal follbeklar.

Keshlash: ETag/If-None-Match,’Cache-Control’uchun; server-side issiq kalitlardagi kesh.

Paginatsiya: cursor-based, sahifa oʻlchami boʻyicha limitlar; «butun dunyoni ortiqcha yuklab oling».

Yuklamani boshqarish: backpressure, navbatlar, write-yo’llarni bo’lish.

Muvofiqlik: o’qish modelini (strong/eventual) aniq ko’rsatish.

8) Kanareya va xavfsiz joylashtirishlar

Feature flags: relizsiz qoʻshishni boshqaramiz; muammoli funksiyani oʻchirish mumkin.

Canary/Blue-Green: yangi versiyadagi qisman trafik, SLI taqqoslash; degradatsiyada avtootkat.

Shadow traffic: soʻrovlarni «quruq» dastur uchun yangi versiyaga takrorlash.

Schema-migrations: ikki bosqichli - avval kengaytirish (backfill), keyin almashtirish, keyin tozalash.

9) Hujjatlar va DX (Developer Experience)

Yagona portal: interaktiv hujjatlar, misollar, SDK, Postman/Insomnia kolleksiyalari.

Changelog va maqom sahifasi: Oʻzgarishlar va hodisalar haqida RSS/Webhook/pochta.

Xato boʻyicha qoʻllanmalar:’reason _ code → mijozga nima qilish kerak’.

Barqaror sandbox/mock: versiyalar, fiksturlar, degradatsiya ssenariylari (429/5xx), sheriklarning avtostestlari uchun shartnomalar.

10) Xavfsizlik va barqarorlik

Autentifikatsiya: qisqa umr koʻradigan tokenlar, tugmalar rotatsiyasi (JWKS, kid).

Foydalanish huquqi: RBAC/ABAC; siyosatni o’zgartirish mijozlarni buzmasligi kerak → «dry-run» ni bajaring va rad etishlarni oldindan qayd qiling.

Suiiste’molliklardan himoya qilish: WAF, bot-filtrlar, anomaliyalar; aniq xato va xizmatning «qulashi» emas.

PII-minimallashtirish: jurnallarda yashirish, anonimlashtirish uchun barqaror sxemalar (tahlillar buzilmasligi uchun).

11) Javoblar va xatolar patterni

Yagona format:

json
{ "error": { "code": "rate_limit", "message": "Too many requests", "retry_after_ms": 1200, "details": {...} } }

Maqomi: 2xx - muvaffaqiyat; 4xx - aniq kodli mijoz xatosi; 5xx - server muammosi (detallar sizib chiqmasdan).

Idempotent maqomi: takrorlash uchun asl’resource _ id ’/’ transaction _ id’ni qaytaring.

Xato versiyasi: Yangi’reason _ code’ni eskisining semantikasini oʻzgartirmasdan qoʻshing.

12) Tez-tez xatolar va ulardan qanday qochish mumkin

Jim breaking-changes (maydonning nomini oʻzgartirish/oʻchirish) → mijozlarning tushishi. Yechim: kontrakt testlari + sxemalar linterlari.

Retrajlardagi operatsiyalarning tasodifiy dublikatlari. Yechim: idempotent kalitlar va natija izini saqlash.

«Yumshoq» javoblar → p95 o’sib bormoqda. Yechim: proyeksiyalar/’ fields = ’/ixcham formatlar, gzip/br.

Mijozlarda qattiq enum’lar → yangi qiymatlarda pasayish. Yechim: «ignore unknown» siyosati.

Audit va telemetriyani aralashtirish → yuk va chalkashlik. Yechim: turli kanallar/omborlar.

Tashqi qaramlikni rad etishning yagona nuqtasi. Yechim: kesh, CB, funktsional degradatsiya, timeouts.

13) API barqarorligining mini-chek-varaqasi

Kontrakt va muvofiqlik

OpenAPI/AsyncAPI yagona haqiqat manbai sifatida
Muvofiqlik va deprecation policy qoidalari hujjatlashtirilgan
Kontrakt testlari (consumer-driven) CI

Ishonchlilik va perf

Write-operatsiyalarning idempotentligi (kalitlar, TTL, deduplikatsiya)
Rate limiting, retry-policy bilan jitter, paginatsiya cursors
Circuit breaker/bulkhead, kesh, taymautlar

Kuzatish

SLI/SLO, error budget, alyertlar
Correlation id bilan treysing, tarkibiy loglar
Dashbordlar p95/p99/endpoint va versiyalar bo’yicha muvaffaqiyat

Sarlavhalar

Canary/Blue-Green, feature flags, avtoulov
Sxemalarning ikki bosqichli migratsiyasi, shadow-traffic
Hodisalar va postmortem rejasi

DX va kommunikatsiyalar

Hujjatlar/SDK/kolleksiyalar, changelog, maqom sahifasi
Barqaror sandbox va test ma’lumotlari to’plami
Xato kodlari va «mijoz nima qilishi kerak» tavsiyalari

14) Patternlarning qisqa namunalari

Idempotent to’lovi


POST /payments
Idempotency-Key: u123    order456

→ 201 { "payment_id": "p789", "status": "pending" }
Takrorlash → 200 {"payment_id": "p789", "status": "pending"}

Sxemaning xavfsiz evolyutsiyasi

1-qadam: Yangi’customer _ email’(optional) maydonini qoʻshish.

2-qadam: uni serverda toʻldirishni boshlash; o’qishga tayyor bo’lgan mijozlar.

3-qadam: eski’email’ning deprecation’ini sana bilan e’lon qilish.

4-qadam: N oydan keyin ’/v2’ga o’tkazish va’email’ni faqat shu erda o’chirish.

Jitter bilan retraylar


delay = base (2^attempt) + random(0, base)

API barqarorligi - boshqariladigan muhandislik: kontrakt + muvofiqlik + o’lchanadigan maqsadlar + relizlar intizomi. SLO/noto’g’ri byudjet, idempotentlik, kontrakt testlari, kuzatuv va kanareykalarni joriy etadigan jamoalar funksionallikni tezroq va xavfsiz chiqaradi, sheriklar esa ularga ishonishadi. Bu to’g’ridan-to’g’ri pul bugun va ertaga oldindan aytib bo’ladigan pul.