Ozroq memlashamiz )

Responsive o‘rniga hamma joyga !important qo‘yadigan kelin

Merge conflictni hal qila olmaydigan kelin

TypeScriptdan qo‘rqadigan kelin

env faylini gitga push qilib yuborgan kelin

Light mode’da VS Code ishlatadigan kelin

Qolganini izohlarda davom etamiz...😅

Bit.ly qanday ishlaydi? System Design intervyularidagi klassik savolini birga yechamiz

Biz har kuni bit.ly, tinyurl, cuttly kabi qisqa havolalarga duch kelamiz. Ular uzun va xunuk URL manzillarni chiroyli va qisqa ko‘rinishga keltiradi. Lekin kapot ostida bu oddiy vosita qanday ishlashini hech o‘ylab ko‘rganmisiz?

Bu nafaqat qiziqarli masala, balki bir qator kabi yirik kompaniyalarning System Design suhbatlarida eng ko‘p beriladigan savollardan biridir.

Keling, tasavvur qilamiz: bizga shunday servisni noldan qurish vazifasi topshirildi. Buni qanday amalga oshiramiz?

1-qadam: Talablar va Cheklovlarni aniqlash (Requirements)

Har qanday tizimni loyihalashdan avval, uning funksional va nofunksional talablarini aniqlab olishimiz kerak.

Funksional talablar:

Foydalanuvchi uzun URL manzilni kiritib, unga mos qisqa URL olishi kerak.

Foydalanuvchi qisqa URL manziliga kirganda, u avtomatik tarzda asl uzun manzilga yo‘naltirilishi (redirect) kerak.

Nofunksional talablar:

High Availability: Tizim doim o'chib qolmasligi, limit tugamasligi, buzilmasligi kerak.

Tezkor (Low Latency): Manzilga yo‘naltirish jarayoni deyarli bir zumda amalga oshishi kerak.

Scalibility: Tizim milliardlab havolalarni va ularga bo'ladigan milliardlab murojaatlarni bajara olishi kerak.

Noyoblik (Uniqueness): Har bir qisqa havola faqat bitta asl havolaga bog'langan bo'lishi shart.

2-qadam: API dizayni (API Endpoints)

Tizimimiz bilan tashqi dunyo qanday "gaplashishini" belgilab olamiz. Buning uchun ikkita asosiy endpoint kerak bo'ladi:

1. Havolani qisqartirish uchun:

POST /api/v1/shorten

So'rov (Request Body):

{
  "original_url": "https://uz.wikipedia.org/wiki/Amir_Temur_maqbarasi"
}

Muvaffaqiyatli Javob (201 Created):

{
  "short_url": "https://short.uz/GorAmir"
}

2. Qisqa havoladan asl manzilga yo'naltirish uchun:

GET /{short_code}

Misol: Foydalanuvchi https://short.uz/GorAmir manziliga kiradi. Bu yerda GorAmir — bu bizning short_code.

Javob: Tizim 301 Moved Permanently HTTP status kodi bilan javob qaytaradi. Bu javobning Location header qismida asl uzun URL (https://uz.wikipedia.org/wiki/Amir_Temur_maqbarasi) bo'ladi. Brauzer bu javobni olgach, foydalanuvchini avtomatik tarzda o'sha manzilga yo'naltiradi.

3-qadam: Ma'lumotlar bazasi sxemasi (Database Schema)

Endi ma'lumotlarni qanday saqlashni o'ylab ko'ramiz. Bizga oddiy, lekin samarali jadval kerak. Keling, uni urls deb nomlaymiz. Unda id, original_url, short_code, created_at kabi fieldlar bo'ladi.

4-qadam: Qisqa kodni generatsiya qilish (short_code Generation)

Bu — tizimning eng qiziqarli va muhim qismi. short_code qanday yaratiladi?

Yomon yondashuv: Hashing (masalan, MD5)
Uzun URL'ni MD5 orqali hashlab, natijaning birinchi 6-7 belgisini olish mumkin.

Muammo: To'qnashuv (Collision). Ikki xil uzun URL bir xil qisqa kodga ega bo'lib qolishi ehtimoli bor. Bu esa mutlaqo yaroqsiz yechim.

Yaxshi yondashuv: Base62 Encoding
Bu ancha universal standart hisoblanadi va quyidagicha ishlaydi:

Yangi URL bazaga saqlanganda, unga unique, avtomatik o'suvchi id beriladi (masalan, 1001). Bu raqam 10 lik sanoq tizimida.

Biz bu id raqamini Base62 sanoq tizimiga o'tkazamiz. Nega aynan Base62? Chunki u URL uchun xavfsiz bo'lgan 62 ta belgidan foydalanadi: [0-9], [a-z], [A-Z].

Bu usul collisionlarni oldini 100% oladi, chunki har bir id noyob.

Misol:
id = 1 -> 1 (Base62)
id = 1000 -> gE (Base62)
id = 99999999 -> 15FTGf (Base62)

Ko'rib turganingizdek, hatto 100 millioninchi havola uchun ham kod juda qisqa (6 belgi) chiqadi.

Davomi pastda...

5-qadam: Katta yuklamalarga bardosh berish (Scaling)

Endi tizimni milliardlab so'rovlarga tayyorlaymiz.

Taxminiy hisob-kitob:

Yozish (Write): Oyiga 100 million yangi URL.

O'qish (Read): Odatda, o'qish operatsiyalari yozishdan ancha ko'p bo'ladi. Aytaylik, 10:1 nisbatda. Demak, oyiga 1 milliard redirect.

Bu soniyasiga ~40 ta yozish va ~400 ta o'qish degani. Bu juda katta yuklama!

Qayerda muammo bo'ladi? Asosiy yuklama ma'lumotlar bazasining o'qish operatsiyalariga tushadi.

Yechim №1: KESHLASH (Caching!)
Bu eng muhim optimizatsiya. Biz Redis kabi in-memory keshdan foydalansak bo'ladi.

Mantiq: Foydalanuvchi GET /GorAmir so'rovini yuborganda:

Tizim avval Redis keshidan GorAmir kalitini qidiradi.

Cache Hit (Keshdan topildi): Agar kalit topilsa, unga mos uzun URL keshdan olinadi va foydalanuvchiga bir zumda qaytariladi. Ma'lumotlar bazasiga umuman murojaat qilinmaydi!

Cache Miss (Keshda yo'q): Agar kalit topilmasa, tizim ma'lumotlar bazasiga murojaat qiladi, uzun URL'ni oladi, uni kelajakdagi so'rovlar uchun Redisga saqlaydi va keyin foydalanuvchiga qaytaradi.

Bu yondashuv ma'lumotlar bazasiga tushadigan yuklamani 90-95% gacha kamaytiradi.

Yechim №2: Ma'lumotlar bazasini kengaytirish (Database Sharding)
Agar bitta ma'lumotlar bazasi milliardlab yozuvlarni saqlashga qiynalsa, biz ma'lumotlarni bir nechta bazalarga bo'lib tashlaymiz. Bu jarayon Sharding deyiladi.

Mantiq: short_code ning birinchi belgisiga qarab ma'lumotlarni bo'lishimiz mumkin. Masalan, 'a' dan 'm' gacha boshlanadigan barcha kodlar 1-bazaga, 'n' dan 'Z' gacha bo'lganlar esa 2-bazaga yoziladi. Bu ham yozish, ham o'qish yuklamasini taqsimlaydi.

Ko'rib turganingzdek, oddiy tuyulgan masalaga ham o'zgacha yondashish, iloji boricha ko'proq nimaga va qanday degan savollar berib chiqish muhim hisoblanadi. Hozir men bu muammoga yechimni iloji boricha qisqa va tushunarliroq shaklda yozishga harakat qildim, lekin buniyam turli xil yechimlar va yo'llar bilan yanayam samaraliroq va yaxshiroq qilish imkoniyatlari bor.

Hozircha faqat matn ko'rinishida yozishga sharoit bo'lyapti, lekin keyinroq shu mavzularni youtubega video shaklda joylashni boshlayman va shunda tushunishga osonroq va oddiyroq bo'ladi deb o'ylayman

@mabrur_dev

ias)*&U£$*(QYU894erujalksfj012

Ko'p loyihalarda, ayniqsa jamoa kattalashganda, Gitni boshqarish haqiqiy bosh og'rig'iga aylanadi. Kimdir main'ga to'g'ridan-to'g'ri commit qiladi, boshqasi hali pishmagan feature'ni merge qilib yuboradi va production'dagi kod "sinadi".

Bunday holatlarga tushmaslik uchun ancha tartibli va sinovdan o'tgan Gitflow workflowidan foydalansa bo'ladi. Bu flowni yana bir yaxshi tomoni muntazam versiyalarga (versioned releases) ega bo'lgan loyihalar uchun ham ideal yechim.

Hozir bu workflow ishlashini sodda tilda tushunishga harakat qilamiz.

Menda ikkita doimiy (long-lived) branch bor:

🌳 Master/Main branch:
Bu - production'dagi, ya'ni real foydalanuvchilar ishlatayotgan eng barqaror va toza kod. Bu yerga to'g'ridan-to'g'ri hech narsa commit qilinmaydi! Main'dagi har bir commit - bu yangi versiya (release) degani va u v1.0.1, v1.1.0 kabi tag'lar bilan belgilanadi.

🌿 Develop branch:
Bu - bizning asosiy ish maydonimiz. Barcha yangi feature'lar shu yerga yig'iladi. Develop branch'i kelajakdagi release uchun tayyorlanayotgan kodning eng so'nggi holatini saqlab yuradi.

Endi esa, asosiy ishni bajaradigan vaqtinchalik (short-lived) branch'lar:

💡 Feature branch (feature/*)
Har bir yangi feature (funksionallik) uchun men develop'dan alohida feature/task-111-user-authentication kabi yangi branch ochaman. Bu ishni boshqa feature'lardan to'liq izolyatsiya qiladi. Feature tayyor bo'lib, code review'dan o'tgach, u develop'ga merge qilinadi va o'chiriladi.

📦 Release branch (release/*)
develop'da keyingi versiya uchun kerakli feature'lar yig'ilgach, men release/v1.1.0 kabi yangi release branch'ini yarataman. Bu branch'da faqat release'ga tayyorgarlik ishlari qilinadi: oxirgi bug'lar tuzatiladi, dokumentatsiya yangilanadi, versiya raqami o'zgartiriladi. Yangi feature qo'shilmaydi.
Release tayyor bo'lgach, u bir vaqtning o'zida:
- main'ga merge qilinadi va tag bilan belgilanadi (bu endi production'dagi kod).
- develop'ga ham merge qilinadi (chunki release branch'da qilingan o'zgarishlar develop'da ham bo'lishi kerak).
Keyin bu release branch ham o'chiriladi.

🔥 Hotfix branch (hotfix/*)
Tasavvur qiling, production'da shoshilinch bug chiqib qoldi va uni darhol tuzatish kerak. Bunday paytda men develop'ga tegmasdan, to'g'ridan-to'g'ri main'dan hotfix/task-212-login-bug kabi branch ochaman. Bug tuzatilgach, bu hotfix branch xuddi release kabi ham main'ga, ham develop'ga merge qilinadi. Bu develop'da eski bug'ning qayta paydo bo'lishining oldini oladi.

Xulosa qilib aytganda, bu workflow kodni toza saqlashga, jamoaviy ishni tartibga solishga va release'larni oson boshqarishga yordam beradi. Loyihangiz biroz murakkablashishi bilan uning afzalliklarini seza boshlaysiz.

Siz o'z loyihalaringizda qanday Git branching strategy'sidan foydalanasiz? Izohlarda tajribangiz bilan bo'lishing! 👇

@mabrur_dev

Eshitdilarmi, Apple yashirincha IOS'ni fundamental qismlarini qayta yozib chiqyaptimish. Bu Swift yoki Objective-C damas, umuman boshqa tilda - Rustda bo'larkan!

Iphoneni quyi qismlari - xotira boshqaruvi, concurrency, applar crash bo'lgandagi holatlar Rust g'oyalari bilan qayta qurib chiqilayotgan ekan.

Bu haqida hali to'liq ko'rib chiqmadim, bilganlar bo'lsa kommentariyada yozib ko'proq ma'lumot berselar bo'ladi

Osonakanu ishilar )

Rate Limiting - Backenddagi Qalqon🛡️

Siz o'z tizimingizga qancha resurs ajratmang, uning baribir o'z chegarasi bor. Ba'zida trafik kutilmaganda keskin oshadi (bursts), userlar agressiv retry qiladi yoki bitta servisdagi muammo butun tizimni ishdan chiqaradi. Aynan shunday paytlarda Rate Limiting (so'rovlarni cheklash) ancha as qotadi.

Oddiy qilib aytganda, Rate Limiter - bu API oldida turgan "qo'riqchi" (bouncer). U tizimga kirayotgan so'rovlar oqimini nazorat qilib turadi, serverlarni haddan tashqari yuklanishiga, brute-force hujumlariga va boshqa shunga o'xshash holatlarga yo'l qo'ymaydi. Agar klient belgilangan me'yordan oshsa, Rate Limiter unga ko'pchilik ko'rgan 429 Too Many Requests xatoligini qaytaradi.

Hozir eng keng tarqalgan Rate Limiting algoritmlarini ko'rib chiqamiz:

1. Fixed Window Counter
Bu eng oddiy usul. Vaqt qat'iy oraliqlarga ("windows") bo'linadi (masalan, har daqiqada). Har bir oyna uchun so'rovlar hisoblagichi (counter) bo'ladi.

Qanday ishlaydi: Agar daqiqasiga 100 ta so'rov limiti bo'lsa, 14:00 da hisoblagich 0 ga tushadi va 14:01 gacha kelgan so'rovlarni sanaydi. 101-so'rov rad etiladi. 14:01 da hisoblagich yana 0 ga tushadi.

Asosiy muammo: Oyna chegarasidagi yuklama. Masalan, klient 14:00:59 da 100 ta va 14:01:01 da yana 100 ta so'rov yuborishi mumkin. Natijada tizim 2 soniya ichida 200 ta so'rov qabul qiladi, bu esa limitimizda yanayam qo'shimcha limitlar keltiradi.

2. Sliding Window Log
Bu usul yuqoridagi muammoni hal qiladi. U har bir so'rovning timestamp'ini (vaqt belgisini) saqlaydi.

Qanday ishlaydi: Yangi so'rov kelganda, algoritm joriy vaqtdan bir oyna (masalan, 1 daqiqa) orqadagi barcha timestamp'larni o'chiradi. Qolgan timestamp'lar soni limitdan oshmasa, so'rov qabul qilinadi va uning timestamp'i jurnalga qo'shiladi.

Afzalligi: Juda aniq ishlaydi, chegara muammosi yo'q.

Kamchiligi: Har bir foydalanuvchining har bir so'rovi uchun timestamp saqlash katta trafikda juda ko'p xotira talab qilishi mumkin.

3. Sliding Window Counter
Bu - avvalgi ikki usulning yaxshi tomonlarini birlashtirgan gibrid yondashuv, "oltin o'rtalik".

Qanday ishlaydi: Bu usul timestamp'lar jurnalini saqlamaydi. Buning o'rniga, u oldingi va joriy oynalardagi hisoblagichlardan foydalanib, sliding windowdagi so'rovlar sonini taxminan hisoblaydi. Bu orqali resurs sarfiyam, aniqligam yaxshi muvozanatlanadi.

Afzalligi: Xotirani tejamkorligi va yetarlicha aniqlik. Ko'pgina yirik tizimlar aynan shu yondashuvdan foydalanadi.

4. Token Bucket
Bu eng mashhur va moslashuvchan strategiyalardan biri.

Tasavvur qiling, bir chelak (bucket) bor va unga doimiy tezlikda "token"lar solib turiladi. Har bir kiruvchi so'rov o'tish uchun chelakdan bitta token olishi kerak. Agar chelakda token bo'lmasa, so'rov rad etiladi yoki navbatga qo'yiladi.

Eng muhim xususiyati: Qisqa muddatli keskin yuklamalarga (bursts) ruxsat beradi. Agar chelak tokenlarga to'la bo'lsa, klient bir vaqtning o'zida chelak sig'imicha so'rov yuborishi mumkin. Bu tizimga moslashuvchanlik beradi.

5. Leaky Bucket
Bu strategiya Token Bucket'ga o'xshaydi, lekin boshqacha maqsadda xizmat qiladi.

Qanday ishlaydi: Kiruvchi so'rovlar qanchalik tez kelishidan qat'iy nazar, chelakka (bu yerda u FIFO - first in first out navbati) tushadi. Chelak esa o'z "tubidan" doimiy bir xil tezlikda so'rovlarni "oqizib" chiqaradi va tizimga uzatadi. Agar chelak (navbat) to'lib qolsa, yangi so'rovlar rad etiladi.

Eng muhim xususiyati: Chiquvchi oqimni doimiy bir tekis tezlikda ushlab turadi. U burst'larni "siyqallaydi" va tizimga so'rovlarni barqaror oqimda yetkazib beradi.

Xulosa qilib aytadigan bo'lsak, eng yaxshi algoritm yo'q. Tanlov sizning talablaringizga bog'liq: agar tizimingiz qisqa muddatli burst'larni qabul qila olsa, Token Bucket yaxshi tanlov. Agar sizga tizimga tushadigan yuklamani doimiy va bir tekisda ushlab turish muhim bo'lsa, Leaky Bucket yoki Sliding Window strategiyalari ko'proq mos keladi.

@mabrur_dev

Intervyuda ko'p uchraydigan savollardan biri: Cookies vs Sessions, Asosiy farqlari nimada?

Javoblarni kutaman.

Sonnet 4.5 chiqdi. Kutilmalar katta, ko'ramiz qanchalik kuchaydi, token usage qanchalik optimize qilingan, yoki yanayam qimmatlashdimi

Prompt engineering, prompt yozdirish va promptni debug qilish bo'yicha gemini 2.5 pro ga teng keladigan model yo'q. Codingda Claudega. Umumiy kundalik ishlarda esa GPTga.

Har kuni 3-4 xil model ishlatib yuradigan inson sifatida, tajribamdan kelib chiqib aytayotgan fikrlarim, noto'g'ri aytayotgan bo'lsam to'g'irlang )

Efirda reklama, lekin bu safargisi foydali )

Kimdir shaxsiy proyektini "tuzukroq" joyga, ortiqcha bosh og'riqsiz deploy qilmoqchi bo'lsa, sizga juda zo'r maslahatim bor.

O'zim doim ishlatib yurgan servisni sizgayam ilindim.

O'zimiziklarga maxsus "jigarlik" havolasi:
👉 https://railway.com?referralCode=NajBle

Shu referal havoladan o'tib ro'yxatdan o'tsangiz, sizga $20 depozit sovg'a qilinadi. Menam quruq qolmayman (akkountimga 15% daromad)

Ana xolos😕

Atmos payment integration bilan ishlab ko'rganlar bormi? Dokumentatsiyasini o'qigandim paymentlar uchun yaxshi solutionlari bor ekan. Stabillik, support va foizlari qanaqa, xabarilar bormi, maslahat berasilarmi?

💥 Hayotimdagi eng qimmatga tushgan 𝐧𝐩𝐦 𝐬𝐭𝐚𝐫𝐭.

Taxminan bir oy oldin LinkedIn'dan bir HR yozib qoldi. Profiliga qaraganda hamma narsa joyida edi: rasmi bor, o‘zi haqida aniq yozgan, 500 ga yaqin "connection"lari bor, hatto orasida men shaxsan taniydigan odamlar ham bor ekan.

U Web3 bo‘yicha ish taklif qildi: to‘liq masofaviy, talablari uncha ko‘p emas, "stack"imga ham rosa mos tushardi. Xuddi osmondan tushgandek, orzuyingdagidek takliflardan biri edi-da.

CV'mni jo‘natdim. Deyarli darhol javob keldi: “Zo‘r! Test topshirig‘ini hoziroq boshlayvering.”

Biroz g‘alati tuyuldi: na intervyu bor, na suhbat. Shunchaki "testni qiling". Lekin topshiriq oddiy edi: kichkina proyektni bir ko‘rib chiqish. Xullas, reponi "clone" qildim, o‘zimda ishga tushirdim... va ortiqcha o‘ylab ham o‘tirmadim.

⏳ Bir necha soatdan keyin kripto hamyonimni ochsam... dong qotib qoldim. Balansda deyarli pul qolmagandi.

Hech qanaqa fishing ssilka bosmadim. Soxta saytlarga kirmadim. Shubxali "approve" (tasdiqlash) bermadim. Shunchaki... hammasi yo‘q bo‘lib qoldi.

Tun bo‘yi kodni titkilab chiqib, axiyri sababini topdim. Gap shundaki, proyekt ichida zararli "dependency" (bog‘liqlik) bor ekan. U ishga tushishi bilan yashirin skript ham avtomatik ishlab ketgan. U "environment variables", hamyon ma’lumotlari, sessiya tokenlarini bildirmasdan yig‘ib, begona serverga jo‘natib yuborgan.

O‘sha soniya menga $25,000 ga tushdi va ishlash uslubimni butunlay o‘zgartirib yubordi.

🧠 O‘shandan beri: • Notanish proyektlarni faqat Docker yoki virtual mashinada (VM) ishga tushiradigan bo‘ldim. • npm install qilishdan oldin har bir "dependency"ni obdon tekshiraman. • Asosiy pulimning hammasi Ledger'da (sovuq hamyonda) turadi.

Chunki dasturchi xavfsizligi bu shunchaki kuchli parol yoki VPN ishlatish degani emas. Ba’zan hammasi bitta kichkina qarorga — npm start tugmasini bosish yoki bosmaslikka bog‘liq bo‘lib qolar ekan.

💬 $25 ming yo‘qotish alamli. Lekin har doim ishimning oddiy bir qismi deb hisoblagan narsamga bo‘lgan ishonchni yo‘qotish undan ham og‘irroq ekan.

Agar siz ham Web3 sohasida ishlasangiz yoki hamyonlar bilan integratsiya qilsangiz, iltimos, mening xatoimni takrorlamang.

(c) Daria Kazantceva

@mabrur_dev