Noldan SaaS mahsuloti: arxitektura, multi-ijara va billing

SaaS oddiy veb-ilovadan interfeysi bilan emas, balki bitta kod bazasi va bitta infratuzilma bir vaqtda koʻplab mustaqil mijozlarga xizmat koʻrsatishi bilan farq qiladi. Aynan shundan barcha asosiy muhandislik qarorlari kelib chiqadi: ijarachilar maʼlumotlarini qanday ajratish, obunalar boʻyicha pulni qanday hisoblash, foydalanishni qanday tariflash va har olti oyda tizimni qaytadan yozmasdan qanday oʻsish kerak. Quyida ortiqcha marketingsiz amaliy tahlil.

Multi-ijara: maʼlumotlarni ajratishning uch modeli

Multi-ijara (multi-tenancy) — bu turli mijozlarning maʼlumotlarini umumiy tizimda saqlash va ajratish usuli. Model tanlovi infratuzilma narxini, ishlab chiqish tezligini va izolyatsiya darajasini belgilaydi. Amalda uchta yondashuv qoʻllaniladi.

• Umumiy sxema, umumiy tenant_id ustuni. Barcha ijarachilar bitta jadvallarda yashaydi, qatorlar mijoz identifikatori bilan belgilanadi. Arzon, masshtablash oson, lekin intizom talab qiladi: har bir soʻrov tenant_id boʻyicha filtrlanishi shart.
• Har bir ijarachiga sxema. Bitta baza, lekin har mijozda oʻz sxemasi. Izolyatsiya yaxshiroq, alohida mijozni zaxiralash osonroq, lekin yuzlab sxemada migratsiyalar murakkablashadi.
• Har bir ijarachiga baza. Maksimal izolyatsiya, yirik korporativ va tartibga solinadigan mijozlar (banklar, tibbiyot) uchun mos. Ekspluatatsiyada qimmat va avtomatlashtirish qiyin.

Billing va obunalar: eʼtibordan chetda qoldirib boʻlmaydigan oʻzak

Billing birinchi prodakshngacha oddiy koʻrinadi. Aslida obuna mantigʻi — bu holatlar avtomati: trial, active, past_due, grace period, suspended, canceled, refunded. Har bir holat funksiyalarga kirishga va hisob-fakturalashga taʼsir qiladi. Buni kod boʻylab tarqoq if-larga joylasangiz, qoʻllab-quvvatlash doʻzaxga aylanadi.

Billingning asosiy komponentlari:

• Tariflar va funksiyalar katalogi — rejaga nima kiradi, qanday limitlar, qaysi funksiyalar yoqilgan.
• Obunalar — «ijarachi + reja + davr + holat» bogʻlamasi, oʻzgarishlar tarixi bilan.
• Hisob-faktura mantigʻi — invoyslarni yaratish, davr oʻrtasida apgreyd/daungreydda proporsional qayta hisoblash (proration).
• Toʻlov qatlami — provayderlar bilan integratsiya va toʻlov vebhuklarini qayta ishlash.
• Rekonsiliatsiya — obuna holatini haqiqiy toʻlovlar bilan solishtirish. Bitta hisoblagichni hech qachon haqiqat deb bilmang.

Oʻzbekiston realliklari haqida alohida: xalqaro Stripe/Paddle bu yerda lokal toʻlovlarni qabul qilish uchun toʻgʻridan-toʻgʻri ishlamaydi. Ishchi sxema — lokal provayderlar bilan integratsiya: Payme, Click, Uzum. Har birida oʻz vebhuk modeli, imzo tekshiruvi va qaytarish talablari bor. Toʻlov shlyuzi abstraksiyasini eng boshidan qoʻying — toki ikkinchi va uchinchi provayderni qoʻshish obuna oʻzagini buzmasin.

Tariflar: qiymatni qanday paketlash

Tariflash modeli — bu daromadga toʻgʻridan-toʻgʻri taʼsir qiluvchi mahsulot qarori. Asosiy sxemalar:

Amaliyot tasdiqlagan bir necha qoida:

• Narxni mijoz uchun qiymat bilan birga oʻsadigan metrikaga bogʻlang (xodimlar soni, qayta ishlangan buyurtmalar, qurilmalar), texnik yukka emas.
• Limitlarni yumshoq qiling: ogohlantirish va greys keskin oʻchirishdan koʻra yaxshiroq, chunki keskin oʻchirish oqimni keltirib chiqaradi.
• Tariflarni kod emas, maʼlumot sifatida saqlang. Yangi reja yoki aksiya reliz talab qilmasligi kerak.

Oʻzbekiston bozori uchun narxlar koʻpincha soʻmda koʻrsatiladi, korporativ segment esa shartnoma va ESF (elektron hisob-faktura)ga oʻrgangan. Yuridik shaxslarga sotsangiz, billing nafaqat kartadan yechishi, balki buxgalteriya uchun maʼlumotlarni chiqara olishi ham kerak.

Masshtablash: avval oʻlcha, keyin boʻl

Erta murakkablashtirish — keng tarqalgan kasallik. 50 mijoz bosqichida mikroservislar, Kubernetes va shardlash koʻpincha foydadan koʻra zarar keltiradi. Toʻgʻri yoʻl — metrikalarga tayanib, tor joylar boʻyicha oʻsish.

• Vertikal va kesh orqali startda: bazadagi indekslar, qaynoq soʻrovlarni keshlash, ulanishlar puli (PostgreSQL uchun PgBouncer).
• Stateless qatlam uchun gorizontal: balanslagich ortida bir necha ilova instansi, fon vazifalari navbatlarda.
• tenant_id boʻyicha shardlash — faqat bitta baza haqiqatan ham yetmay qolganda. Yaxshi xabar: toʻgʻri multi-ijarada tenant_id allaqachon tabiiy shardlash kaliti boʻladi.
• Hududiy yaqinlik: oʻzbek auditoriyasi uchun ES/AQSh serverlarigacha latentlik sezilarli. Lokal hosting yoki foydalanuvchiga yaqin read-replika kabinet javobini sezilarli yaxshilaydi.

Metrikalar: boshqarish uchun nimani oʻlchash kerak

Metrikalarsiz SaaS — koʻr-koʻrona uchish. Avtomatik hisoblanishi kerak boʻlgan minimal toʻplam:

• MRR / ARR — muntazam oylik va yillik daromad, butun obuna iqtisodiyotining asosi.
• Churn — mijozlar oqimi va daromad oqimi (revenue churn logotiplardan muhimroq).
• LTV va CAC — mijozning umrbod qiymati uni jalb qilish narxiga nisbatan; sogʻlom LTV/CAC nisbati 3 va undan yuqori.
• Activation — kalit harakatga (birinchi haqiqiy qiymatga) yetgan mijozlar ulushi, shunchaki roʻyxatdan oʻtganlar emas.
• Expansion / NRR — apgreyd va qoʻshimcha oʻrinlar hisobiga mavjud mijozlarda daromadni oshirish.

Texnik jihatdan metrikalarni jadvallarning joriy kesimiga emas, hodisalar logiga (event log) qurish maʼqul: shunda tarixni tiklay olasiz va sxema oʻzgarganda faktlarni yoʻqotmaysiz.