Stateless service — har bir so‘rovni oldingi so‘rovlarga bog‘liq bo‘lmagan holda qayta ishlaydigan, mijoz sessiyasining zarur holatini mahalliy xotirada doimiy saqlamaydigan xizmatdir. So‘rovni bajarish uchun kerakli kontekst so‘rovning o‘zida yoki umumiy tashqi saqlash tizimida mavjud bo‘ladi. Shu xususiyat nusxalarni almashtirish va gorizontal masshtablashni osonlashtiradi.
Holatning joylashuvi
Stateless degani tizimda umuman state yo‘q degani emas. Foydalanuvchi, buyurtma yoki ruxsat ma’lumoti database, distributed cache yoki object storage’da saqlanishi mumkin. Muhim farq — istalgan service instance navbatdagi so‘rovni lokal sessiyaga muhtoj bo‘lmasdan bajara oladi.
Authentication token so‘rov bilan yuborilishi mumkin, lekin uning imzosi, amal qilish muddati va bekor qilish siyosati tekshiriladi. Token ichiga ortiqcha yoki tez eskiradigan ma’lumot joylash xavfsizlik hamda yangilanish muammosini keltiradi. Server-side session ishlatilsa ham umumiy session store orqali instance’lardan mustaqil bo‘lish mumkin.
Masshtablash va tiklanish
Load balancer so‘rovni sog‘lom nusxalardan istalganiga yuboradi. Sticky session talab qilinmagani sabab trafikni teng taqsimlash sodda. Instance ishdan chiqsa, undagi lokal sessiya yo‘qolmaydi; orchestration tizimi yangi nusxani tez almashtirishi mumkin.
Autoscaling so‘rov soni, CPU yoki navbat chuqurligiga qarab replika sonini o‘zgartiradi. Biroq tashqi database va cache ham oshgan yukni ko‘tara olishi kerak. Stateless frontend masshtablangani bilan stateful backend bottleneck bo‘lib qolishi mumkin.
So‘rov semantikasi
Network timeoutdan keyin mijoz bir so‘rovni qayta yuborishi ehtimol. O‘qish amallari odatda xavfsiz, yozish amallari esa takroriy effekt yaratmasligi uchun idempotency key ishlatishi mumkin. Xizmat kalit va avvalgi natijani umumiy saqlashda tekshiradi.
Stateless servis uzoq davom etadigan workflow’ni butunlay process memory’da tutmaydi. Holat workflow engine, queue yoki database’da checkpoint qilinadi. Background job identifikator bilan bog‘lanib, boshqa worker tomonidan davom ettirilishi mumkin.
Cheklovlar
Har so‘rovda kontekst yuborish tarmoq hajmini oshirishi mumkin. Tashqi state store’ga tez-tez murojaat latency va availability bog‘liqligini keltiradi. Mahalliy cache ishlatilsa, u source of truth emasligi, eskirish muddati va invalidation qoidasi aniq bo‘ladi.
WebSocket yoki real-time subscription kabi uzoq ulanishlar tabiatan ma’lum connection state saqlaydi. Bunday tizim to‘liq stateless bo‘lmasligi mumkin; gateway connectionni ushlab, biznes holatini tashqi tizimda saqlaydi. Drain va reconnect mexanizmi deployment vaqtida ulanishlarni boshqa nusxaga ko‘chirishga yordam beradi.
Loyihalash mezonlari
Service instance qayta ishga tushirilganda qaysi ma’lumot yo‘qolishi mumkinligi tekshiriladi. Configuration va secret tashqi boshqaruvdan olinadi, doimiy fayl lokal diskka bog‘lanmaydi. Health check, graceful shutdown va retry siyosati stateless arxitekturani amaliy jihatdan ishonchli qiladi.
Deterministik konfiguratsiya
Instance’lar bir xil so‘rovga bir xil biznes qoidasi bilan javob berishi uchun konfiguratsiya versiyasi nazorat qilinadi. Rolling deployment vaqtida eski va yangi nusxalar bir muddat yonma-yon ishlaydi, shuning uchun API, schema va message format backward-compatible bo‘lishi kerak. Lokal vaqt, tasodifiy son yoki instance identifikatoriga yashirin bog‘liqlik natijani farqlashi mumkin. Distributed tracing qaysi nusxa so‘rovni qayta ishlaganini ko‘rsatadi, lekin loglar lokal diskda qolmasdan markaziy tizimga yuboriladi. Warm cache yo‘qolishi restartdan keyingi vaqtinchalik latency oshishini tushuntiradi.
Readiness tekshiruvi instance konfiguratsiyani olgani va dependency’lar bilan ishlashga tayyorligini tasdiqlamaguncha load balancer unga real trafik yubormaydi.
Bog‘liq tushunchalar
Stateful service, Horizontal scaling, Load balancer, Idempotency, Session store, Autoscaling