24/7 ishlaydigan transport platformalarni qanday yaratish

Nega transport platforma oddiy sayt yoki ilovadan farq qiladi

Transport platforma — bu shunchaki buyurtma qabul qiladigan sayt yoki haydovchiga ko‘rsatuvchi mobil ilova emas. Bu real vaqt rejimida ishlaydigan tizim: bir vaqtning o‘zida yuzlab yoki minglab buyurtma, haydovchi, transport vositasi va mijoz holatini kuzatib boradi, ularni bir-biriga bog‘laydi va qaror qabul qiladi. Bunday tizimning to‘xtashi — bu shunchaki «sayt ochilmayapti» degani emas. Bu yetkazib berilmagan buyurtma, qo‘lda hisoblanadigan yo‘nalish, jahli chiqqan mijoz va to‘g‘ridan-to‘g‘ri yo‘qolgan daromad degani.

Aynan shu sababli transport platformasini loyihalashda asosiy savol «qanday ko‘rinishga ega bo‘ladi» emas, balki «soat 3:00 da, eng yuqori yuklamada, bir server ishdan chiqqanda nima bo‘ladi» bo‘lishi kerak. 24/7 ishlash — bu qo‘shimcha xususiyat emas, balki butun arxitektura quriladigan poydevor. Quyida biz O‘zbekiston sharoitida (logistika, taksi-agregatorlar, kuryerlik, davlat transport tizimlari) shunday platformalarni qanday qurish kerakligini amaliy nuqtai nazardan ko‘rib chiqamiz.

Real vaqt arxitekturasi: ma’lumot to‘xtamasligi kerak

Transport platformasining yuragi — bu doimiy ma’lumot oqimi. Haydovchining GPS-koordinatasi har necha soniyada yangilanadi, buyurtma holati o‘zgaradi, mijoz xaritada mashinani kuzatadi. Bu yerda klassik «so‘rov yubor — javob ol» modeli yetarli emas. Buning o‘rniga doimiy ulanish texnologiyalari kerak:

• WebSocket yoki MQTT — haydovchi va mijoz ilovasi server bilan uzluksiz aloqada turadi, holat o‘zgarishi darhol uzatiladi.
• Navbat tizimlari (message queue) — Kafka, RabbitMQ yoki shunga o‘xshash vositalar buyurtmalar oqimini server yuklamasidan ajratadi. Yuklama ko‘paysa ham hech bir buyurtma yo‘qolmaydi, navbatda kutadi.
• Geo-indekslangan bazalar — «menga eng yaqin 5 ta bo‘sh mashina» kabi so‘rovlar millisekundlarda javob berishi uchun PostGIS yoki Redis Geo kabi maxsus vositalar ishlatiladi.

Muhim qoida: ma’lumotni qabul qilish (ingestion) va uni qayta ishlash (processing) bir-biridan ajratilishi kerak. Agar haydovchidan kelayotgan koordinata to‘g‘ridan-to‘g‘ri asosiy bazaga yozilsa va shu bazada og‘ir hisob-kitob ishlayotgan bo‘lsa, butun tizim sekinlashadi. Koordinata oqimi alohida, tezkor qatlamga tushishi, asosiy biznes-logika esa undan mustaqil ishlashi lozim.

Uzluksizlik: bitta nuqta ham butun tizimni yiqitmasligi kerak

24/7 ishlashning asosiy dushmani — yagona ishdan chiqish nuqtasi (single point of failure). Agar butun platforma bitta serverda, bitta bazada ishlasa, o‘sha bitta komponent yiqilganda hamma narsa to‘xtaydi. Shuning uchun ortiqchalik (redundancy) printsipi har bir qatlamga kiritilishi kerak:

• Server darajasida: kamida ikkita ilova serveri yuk balanslagich (load balancer) orqasida ishlaydi. Biri yiqilsa, ikkinchisi yuklamani o‘ziga oladi.
• Baza darajasida: asosiy baza (primary) va uning real vaqt nusxasi (replica). Asosiy baza ishdan chiqsa, nusxa uning o‘rnini egallaydi (failover).
• Geografik darajada: agar platforma muhim bo‘lsa, ma’lumot va xizmatlar bir nechta hududda joylashtiriladi. Bu, ayniqsa, xalqaro yetkazib berish yoki tashqi kanallarga bog‘liq tizimlar uchun muhim.

Alohida e’tibor — deploy paytidagi uzilishlar. Yangilanish chiqarish butun platformani to‘xtatmasligi kerak. Buning uchun «blue-green» yoki «rolling» deploy usullari qo‘llaniladi: yangi versiya eski versiya yonida ko‘tariladi, sinovdan o‘tadi, so‘ng trafik asta-sekin unga o‘tkaziladi. Bir narsa noto‘g‘ri ketsa — bir soniyada eski versiyaga qaytish (rollback) imkoni bo‘lishi shart.

Tashqi integratsiyalar: eng zaif bo‘g‘in

Transport platformasi hech qachon yolg‘iz ishlamaydi. U to‘lov tizimlari (Payme, Click, Uzum, bank kartalari), SMS va push-bildirishnoma kanallari, xarita provayderlari, davlat tizimlari (soliq, ОФД, ehtimol GAI yoki bojxona) bilan bog‘lanadi. Bu integratsiyalarning har biri — tashqi tizim bo‘lib, siz uning ishlashini nazorat qila olmaysiz.

Asosiy printsip: tashqi xizmatning yiqilishi sizning platformangizni yiqitmasligi kerak. Buning uchun:

• Timeout va retry: har bir tashqi so‘rovda aniq vaqt chegarasi bo‘lishi va muvaffaqiyatsiz urinish oqilona qayta takrorlanishi kerak.
• Circuit breaker: agar tashqi xizmat ketma-ket bir necha bor javob bermasa, platforma uni «vaqtincha o‘chirilgan» deb belgilaydi va bekorga kutib turmaydi — boshqa yo‘ldan davom etadi yoki buyurtmani navbatga qo‘yadi.
• Idempotentlik: to‘lov yoki buyurtma so‘rovi takrorlansa ham, ikki marta hisoblanmasligi kerak. Har bir operatsiya yagona identifikator bilan belgilanadi.

O‘zbekiston sharoitidagi alohida nozik nuqta — tarmoq barqarorligi. Ba’zi tashqi xizmatlar IP-cheklov qo‘yadi yoki ma’lum kanallar orqali sekin ishlaydi. Shuning uchun muhim integratsiyalar uchun zaxira yo‘nalish (masalan, ishonchli serverdagi relay) oldindan o‘ylangani ma’qul.

Monitoring: muammoni mijozdan oldin bilish

24/7 tizimda eng yomon holat — bu muammoni mijozning shikoyatidan bilib olish. Yaxshi qurilgan platforma o‘zini doimiy kuzatadi va nosozlikni odamlar sezishidan oldin signal beradi. Monitoring uch qatlamdan iborat bo‘lishi kerak:

• Infratuzilma: server yuklamasi, xotira, disk, tarmoq. Disk to‘lib qolishi yoki xotira yetishmasligi (OOM) — tizimlarni jimgina yiqitadigan eng keng tarqalgan sabablardan biri.
• Ilova: so‘rovlarga javob vaqti, xatolik foizi, navbat uzunligi. Agar buyurtmalar navbati o‘smoqda bo‘lsa — bu yiqilishdan oldingi ogohlantirish.
• Biznes-metrikalar: bu eng muhimi va ko‘pincha unutiladi. «So‘nggi 10 daqiqada nechta buyurtma yaratildi?» degan savol. Agar bu raqam to‘satdan nolga tushsa — texnik metrikalar «yashil» bo‘lsa ham, biror narsa buzilgan.

Ma’lumot xavfsizligi va yaxlitligi

Transport platformasi nozik ma’lumotlarni saqlaydi: mijozlar manzili, telefon raqamlari, harakat tarixi, to‘lov ma’lumotlari. Bu ma’lumotlar himoyalanishi va qonuniy talablarga (shaxsiy ma’lumotlarni mahalliy serverlarda saqlash bo‘yicha O‘zbekiston qonunchiligi) javob berishi kerak. Bundan tashqari, ma’lumot yaxlitligi muhim: zaxira nusxalar (backup) muntazam olinishi va — eng asosiysi — ularni qayta tiklash sinovdan o‘tkazilgan bo‘lishi kerak. Hech qachon sinab ko‘rilmagan backup — bu backup emas, bu umid.