Shu paytgacha Tizim Dizayni intervyularini uch tomonida ham qatnashib ko‘rdim. Ham qatnashuvchi, ham intervyular va ham kuzatuvchi rolini o‘ynab ko‘rdim. Bu tajribalar menga ba’zi narsalarni yaxshiroq qilishni o‘rgatdi. Va ushbu maqolada men bu haqda batafsil yozmoqchiman.
Kitoblar
Hamma singari men ham bu jarayonni kitoblar o‘qishdan boshlaganman. Kitoblar boshlash uchun juda zo‘r manba, ammo ularda ba’zi kamchiliklar bor. Kitoblar sizga konsepsiyalarni borligini va ularni qanday ishlatishni kichik misollar bilan o‘rgatadi. Ammo haqiqiy intervyuda bu bilim unchalik ham ishlamaydi.
Katta tizimlar dizaynini haqiqatdan ishda tuzib ko‘rganlar bilishadi, bu juda murakkab va ko‘p o‘zgaruvchan jarayon hisoblanadi. Misol uchun URL qisqartiruvchi tizimni dizayn qilishni olaylik. Kitoblar sizga taxminan: "Bu yerda sizga ma’lumotlar bazasi kerak bo‘ladi, bu yerda kesh kerak, bu yerda sizga sharding kerak bo‘ladi..." va hokazo. Ammo haqiqiy intervyuda bu juda murakkab va ko‘p o‘zgaruvchan jarayon hisoblanadi. Kitoblarda ko‘rsatilgan arxitektura har doim ham eng yaxshi javob emas. Ha bugundan boshlab "it depends" degan javobni aytishni va eshitishni o‘rganishimiz kerak.
Real Intervyu
Tasavvur qiling tizimni xuddi kitobda o‘rgatilganidek dizayn qilyapsiz, va birdan sizga "Sekundiga 1 million so‘rovni qanday boshqarasiz?" deb so‘ralsa nima deb javob berasiz? Qanday qilib siz qilayotgan dizayn bu savolga isbotlar bilan javob bera oladi? Sizning javobingizda qanday raqamlar bo‘ladi? Sizning dizayningiz qanday o‘zgaradi?
Afsuski bu savolni intervyu jarayonida menga hech kim berib shok qilmagan. Ammo bu savolni bir ajoyib muhandis tanishim bilan birga muhokama qilgandik. Rostdan ham uyga borib fikrlab ko‘rganimdan keyin kitoblardagi asl kamchilikni tushungandim.
Boshlanishiga siz patternlarga amal qilishga harakat qilasiz, miyangiz esa avtomatik ravishda "Bu yerda kesh kerak, chunki ..." deb javob berishga tayyorlanadi. Lekin sizga yana bir kutilmagan savol yuzlanadi "Agar kelayotgan so‘rovlarning 60% keshga tushmasa, bu kesh tizim uchun hali ham foydalimi yoki u faqat kechikish (latency) va operatsion bosh og‘riq (overhead)larini qo‘shadimi?". Siz muzlab qolasiz. Bu savolga javob berish uchun umidlar so‘nib boradi.
Matematika va Raqamlar
Bu savolga javob berish uchun dizayningizni, dizayningizni o‘zgartirish uchun fikrlash usulingizni, va fikrlash usulingizni o‘zgartirish uchun intervyu jarayoniga yondashuvingizni o‘zgartirishingiz kerak bo‘ladi. Bunda sizga "Matematika" va "raqamlar" yordam beradi. "Trade-off" larni tushunish, keraksiz komponentlarni olib tashlash, va har bir komponentning o‘ziga xos "failure mode"larini tushunish uchun sizga raqamlarni aniqlash yordam beradi.
Intervyuda eng ko‘p takrorlanadigan (o‘zim ham ko‘p bu xatoga yo‘l qo‘yganman) xato - bu "pattern matching" xatosi. Siz intervyu oluvchidan savollar so‘rash o‘rniga unga javob berishga shoshilasiz, va buni natijasida kitobda o‘rgatilgan "pattern"larni avtomatik ravishda qo‘llashga harakat qilasiz. Keling bugundan boshlab avval savollar so‘rashni, keyin o‘ylab ko‘rib shunga nisbatan tizimlarni dizayn qilishni o‘rganamiz. Har bir komponentning o‘ziga xos "failure mode"larini, "trade-off"larini, "raqamlar"ini tushunishga harakat qilaylik.
Savollarga misollar sifatida quyidagilarni so‘rash mumkin:
- Tizimga qancha foydalanuvchi keladi?
- O‘qish va yozish nisbati qanday?
- Tizimga qancha trafik kutilmoqda?
- Tizim qaysi komponenti birinchi bo‘lib buziladi?
- Tizimga qancha trafik kutilmoqda?
- va hokazo.
Yaxshi dizayn
Savollardan keyin istalgan bir komponentni oling, va uning ahamiyati haqida o‘ylang. Database? Yozish amallari yaxshi bajarilsa-yu, o‘qish oqsasa nima qilaman? Kesh? Agar keshga tushadigan so‘rovlar tez-tez o‘chib ketsa, vaqti-vaqti bilan yangilansa nima qilaman? Load balancer? Agar health checklar testdan o‘tsa-yu, lekin xizmat aslida ichida o‘lik (o‘chib qolgan) bo‘lsa nima qilaman?
Har xil ssenariylardan yurib ko‘ring. Ovozni chiqarib o‘ylang, qog‘ozga yozib o‘ylang. O‘ylang. Aynan shu yerda kitoblar ishlamasligini ko‘rasiz. Tajribali bo‘lasiz. Ko‘proq va kengroq fikrlashni o‘rganasiz. Har bir komponentning o‘ziga xos "failure mode"larini, "trade-off"larini, "raqamlar"ini tushunishga harakat qilasiz. Aslida intervyudan maqsad to‘g‘ri dizayn qilish emas, balkim, noaniqlikda fikrlashni, "trade-off"larni raqamlar bilan himoya qilishni, va cheklovlar o‘zgarganda moslasha olishni ko‘rsatishdir.
Redis keshlash uchun, Postgres strong consistency uchun, Kafka esa event streaming uchun, Rust memory safety va tezlik uchun yaxshi tanlovlar. Ammo bu har doim ham to‘g‘ri javob emas.
Xulosa
Men ham yuqoridagi xatolarni qilganman, ammo xato qilish emas, undan xulosa olish muhimroq. Aynan raqamlarni tushunish, hisoblashni boshlagan kunimizdan boshlab sizda yaxshi tizim dizayni bo‘yicha yaxshi qarashlar va tajriba shakllanadi. Big Tech kompaniyalarida ishlovchi muhandislar ham aynan shu hisoblar asosida tizim qurishadi, va bu haqiqatga ancha yaqinroq. Har narsa har qanday vaziyatda ishlaydi degan tushuncha yolg‘on. Siz nimagadir erishish uchun nimadandir doim voz kechasiz. Savollar bilan keraksiz komponentlarni olib tashlaysiz, va har bir komponentning "failure mode", "trade-off" larini o‘rganasiz.
Pattern’lar kod yozishda, algoritmlarda yordam berishi mumkin ammo tizimlarni dizayn qilishda emas. Tizimlarni dizayn qilishni yodlamang, ularni his qilishni va tushunishni o‘rganing.
