Eng muhim 30 ta system design intervyu savoli (+ test!)

Intervyular murakkab, ba'zan hatto qo'rqinchli bo'lishi mumkin. Ular ko'pincha noaniqlik hissi bilan birga keladi, chunki aksariyat hollarda beriladigan savollar ustidan nazoratingiz juda kam yoki umuman yo'q. System design intervyulari esa talabni yanada oshiradi, chunki ular murakkab dasturiy tizimlarni qurish uchun zarur bo'lgan asosiy ko'nikmaga e'tibor qaratadi — xoh startup'lar uchun bo'lsin, xoh Google, Amazon va Facebook kabi yirik big tech kompaniyalari uchun.

Sohada yillar davomida ishlagan tajribali dasturchilar ham system design intervyularini ko'pincha qiyin deb bilishadi. Qiyinchilik faqat texnik bilim bilan bog'liq emas; u fikrlash jarayoningizni aniq tushuntirish, noaniq talablar bilan ishlash va bosim ostida o'ylangan qarorlar qabul qilishni ham talab qiladi. Kompaniyalar siz real hayotdagi, katta miqyosdagi muammolar uchun yechim loyihalay olasizmi yoki yo'qligini baholashda aynan shu savollarga tayanadi.

Ushbu qo'llanmada men sizni system design intervyusidagi 30 ta muhim savol bilan birma-bir tanishtiraman. Asoslardan boshlaymiz, so'ng murakkabroq mavzularga o'tamiz, shuningdek, scenario'ga asoslangan savollarni ham ularga javob berishning amaliy strategiyalari bilan ko'rib chiqamiz. Oxirida system design konsepsiyalariga yondashishda o'zingizni ancha ishonchli his qilasiz va bu pattern'larni samarali qo'llashni bilib olasiz.

Tayyorgarlikni osonlashtirish uchun o'zingizni tezkor sinab ko'rishga mo'ljallangan flashcard'lar to'plamini ham qo'shdim. Agar bu yerda yoritilgan konsepsiyalarni chuqurroq o'rganmoqchi bo'lsangiz, system design roadmap'ini albatta ko'rib chiqing.

System design intervyusiga tayyorgarlik

Ehtimol, “Intervyu berish — bu ko'nikma” degan gapni eshitgansiz. Bu shuni anglatadiki, yaxshilanish uchun ongli harakat va mashq kerak. Boshqa har qanday ko'nikma kabi, soft skill'lar va texnik ko'nikmalarning asoslarini mustahkamlashingiz kerak — shunda javoblaringiz kuchli tomonlaringizni ochib beradi va bu lavozimga aynan siz mos ekaningizni ko'rsatadi. System design intervyusiga borishdan oldin takrorlab olish kerak bo'lgan bir nechta asosiy yo'nalishlar:

• Muloqot ko'nikmalari: Fikrlash jarayoningizni aniq va lo'nda tushuntirishni mashq qiling. Intervyu oluvchilar muammolarni qanday qismlarga ajratishingizni va trade-off'lar haqida qanday mulohaza yuritishingizni ko'rishni xohlashadi.

• Asosiy konsepsiyalar: Load balancing, keshlash, ma'lumotlar bazalari (SQL va NoSQL) hamda API'lar kabi asosiy mavzularni takrorlang. Ular deyarli har bir system design suhbatida uchraydi.

• Scalability va reliability: O'sish, yuqori trafik, fault tolerance va disaster recovery bilan ishlash strategiyalarini muhokama qilishga tayyor bo'ling.

• Trade-off'lar va qaror qabul qilish: System design bitta “to'g'ri” javob haqida emas. Afzallik va kamchiliklarni tortib ko'ra olishingizni va amaliy tanlov qila olishingizni ko'rsating.

• Oldingi tajriba: Ishlagan loyihalaringizdan bu konsepsiyalarni real hayotiy vaziyatlarda qanday qo'llaganingizni ko'rsatadigan misollarni o'ylab qo'ying.

Ba'zi hollarda intervyu oluvchilar quyidagi kabi umumiy savollardan boshlashi mumkin:

• “Qancha vaqtdan beri software engineer yoki backend developer bo'lib ishlayapsiz?” (lavozimingizga qarab)

• “Ma'lumotlar bazasi tizimlari va schema design bo'yicha malakangizni qanday baholaysiz?”

• “Siz qo'llagan keng tarqalgan design pattern'lar qaysilar?”

Bunday “isinish” savollari odatda suhbat ohangini belgilashga va o'zingizni erkinroq his qilishingizga yordam beradi. Bu ma'lumotlarning bir qismi CV yoki rezyumeingizda allaqachon bo'lsa ham, u haqda gapirishga tayyor bo'ling. System design tajribangizni aks ettiradigan aniq va samimiy javoblar berishni mashq qiling.

Shu poydevor tayyor bo'lgach, intervyuga tayyorlanish davomida tanishib chiqishingiz kerak bo'lgan aniq system design savollariga o'taylik.

Flashcard'lar bilan o'zingizni sinab ko'ring

Ushbu flashcard'lardan foydalanishingiz yoki savollarni ro'yxat ko'rinishida ko'rish uchun quyidagi savollar ro'yxati bo'limiga o'tishingiz mumkin.

Savollar ro'yxati

Agar savollarni ro'yxat ko'rinishida ko'rishni afzal ko'rsangiz, ularni quyida topasiz.

Boshlang'ich darajadagi system design intervyu savollari

Consistent hashing nima va u nima uchun foydali?

Consistent hashing — so'rovlar yoki ma'lumotlarni ko'plab serverlar bo'ylab taqsimlash usuli. Uning asosiy afzalligi shundaki, serverlar qo'shilganda yoki olib tashlanganda hamma narsani qaytadan aralashtirish o'rniga ma'lumotlarning faqat kichik qismini ko'chirish kerak bo'ladi.

Serverlar aylana bo'ylab joylashtirilgan deb tasavvur qiling. Har bir ma'lumot bo'lagiga shu aylanada pozitsiya beriladi va u soat mili yo'nalishida harakatlanganda duch kelinadigan birinchi serverda saqlanadi. Bu tuzilma serverlar soni o'zgarganda ham ma'lumot qayerga tegishli ekanini bilishni osonlashtiradi.

Mashhur misol — Amazon DynamoDB. Black Friday kabi yuqori trafikli tadbirlar paytida DynamoDB talabni uddalash uchun qo'shimcha serverlar qo'shishi mumkin. U consistent hashing'dan foydalangani uchun ma'lumotlarning faqat bir qismini yangi serverlarga ko'chirish kerak bo'ladi. Bu umumiy tizim arxitekturasini barqaror va tezkor saqlaydi.

Consistent hashing quyidagi sabablarga ko'ra foydali:

• Scaling'ni silliqroq qiladi, chunki ma'lumotlarning faqat bir qismi ko'chadi.

• Fault tolerance'ni yaxshilaydi, chunki bitta server ishdan chiqqanda uning vazifasini boshqa serverlar o'z zimmasiga olishi mumkin.

• Virtual node'lar yordamida so'rovlarni bir tekisroq taqsimlaydi.

Vertical scaling va horizontal scaling o'rtasidagi farqni tushuntiring.

Scaling — tizimingiz ko'proq foydalanuvchi yoki so'rovni ko'tara olishi uchun uning sig'imini oshirish. Buning ikkita asosiy yo'li bor:

• Vertical scaling — bitta mashinaga ko'proq CPU, RAM yoki saqlash hajmi qo'shib, uni kuchliroq qilish. Bu noutbukingiz tezroq ishlashi uchun unga ko'proq xotira qo'shib yangilashga o'xshaydi.

• Horizontal scaling — ish yukini bo'lishish uchun ko'proq mashina qo'shish. Har biri yuklamaning bir qismini bajaradigan bir nechta noutbukni bir-biriga ulashni tasavvur qiling.

Real tizimlarda:

• Vertical scaling'ni sozlash osonroq, lekin uning chegaralari bor. Bitta mashina faqat ma'lum darajagacha kuchli bo'la oladi va agar u ishdan chiqsa, hamma narsa to'xtab qoladi.

• Horizontal scaling'ni boshqarish qiyinroq, lekin u deyarli cheksiz o'sishi mumkin. Bitta mashina ishdan chiqsa, boshqalari uning ishini o'z zimmasiga oladi va bu tizimni ishonchliroq qiladi.

Load balancer'lar nima va ular nima uchun ishlatiladi?

Load balancer bir nechta server bo'ylab trafikni boshqarishga yordam beradi. Barcha so'rovlarni bitta serverga yuborish o'rniga, u ularni hech bir server ortiqcha yuklanib qolmaydigan tarzda taqsimlaydi.

U gavjum chorrahadagi yo'l harakati nazoratchisi kabi ishlaydi: mashinalarni turli yo'llarga yo'naltiradi, shunda hech bir yo'lda tirbandlik bo'lmaydi. Xuddi shunday, load balancer so'rovlarni ularni eng yaxshi uddalay oladigan serverga yo'naltiradi. U round robin (so'rovlarni har bir serverga navbatma-navbat yuborish) kabi oddiy usullardan yoki yangi so'rovlarni eng kam faol ulanishga ega serverga yuborish kabi aqlliroq usullardan foydalanishi mumkin.

Amazon va Instagram kabi katta miqyosdagi ilovalar tez va ishonchli bo'lib qolish uchun load balancer'larga tayanadi. Ularsiz bitta server og'ir trafik ostida ishdan chiqib, butun ilovani to'xtatib qo'yishi mumkin edi.

Load balancer'lar quyidagi sabablarga ko'ra foydali:

• Serverlarning ortiqcha yuklanishining oldini oladi

• Server ishdan chiqqanda trafikni boshqa serverlarga yo'naltirib, reliability'ni oshiradi

• Yuqori talab ostida ham unumdorlikni bir maromda saqlaydi

CAP teoremasini misollar bilan tushuntiring.

CAP teoremasi distributed system'dagi trade-off'larni tavsiflaydi. Unga ko'ra, tizimingiz bir nechta serverga tarqalgan bo'lsa, bir vaqtning o'zida uchta xususiyatdan faqat ikkitasini kafolatlay olasiz.

• Consistency (C): Har bir foydalanuvchi bir vaqtning o'zida bir xil ma'lumotni ko'radi.

• Availability (A): Ba'zi serverlar ishlamay qolgan bo'lsa ham, har bir so'rov javob oladi.

• Partition tolerance (P): Tarmoqning ayrim qismlari o'zaro bog'lana olmasa ham, tizim ishlashda davom etadi.

Network partition'lar har doim yuz berishi mumkinligi sababli, aksariyat tizimlar Consistency va Availability o'rtasida tanlov qilishi kerak.

Misollar:

• Bank ilovasi (CP) Consistency va Partition Tolerance'ni ustun qo'yishi mumkin. Noto'g'ri hisob balansini ko'rsatgandan ko'ra vaqtincha ishlamay turgani yaxshiroq.

• Facebook kabi ijtimoiy tarmoq platformasi (AP) ko'pincha Availability va Partition Tolerance'ni tanlaydi. Tarmoqda muammo yuz bersa, xato olish o'rniga eskiroq feed'ni ko'rishingiz mumkin.

Keshlash nima? Tizimda keshni qayerga joylashtirgan bo'lardingiz?

Keshlash — tez-tez ishlatiladigan ma'lumotlarni tez olish mumkin bo'lishi uchun ularni tezkor xotirada saqlash. Bu javob vaqtini qisqartiradi va asosiy ma'lumotlar bazasiga tushadigan yuklamani kamaytiradi.

Oddiy o'xshatish: qahva krujkangiz kerak bo'lgan har safar oshxonaga borish o'rniga uni stolingizda saqlash. Bu vaqt va kuchni tejaydi.

Foydalanish holatiga qarab, keshni quyidagi joylarga joylashtirish mumkin:

• Client-side: Brauzerda, rasmlar, stylesheet'lar yoki script'lar kabi statik asset'larni saqlash uchun.

• Ilova darajasida: Serverning xotirasida, Redis yoki Memcached kabi vositalar yordamida. Bu foydalanuvchi session'lari yoki takroriy query'lar kabi narsalar uchun foydali.

• Ma'lumotlar bazasi darajasida: Qimmat query'larning natijalarini saqlash uchun, shunda ularni qayta-qayta bajarish shart bo'lmaydi.

Masalan, Reddit kabi ijtimoiy tarmoq platformasi mashhur post'larni keshlaydi, shunda biror thread viral bo'lib ketganda millionlab foydalanuvchilar uni ma'lumotlar bazasini ortiqcha yuklamasdan ko'ra oladi.

CDN (Content Delivery Network) nima ekanini va undan qachon foydalanishni tushuntiring.

CDN — dunyo bo'ylab joylashtirilgan, rasmlar, videolar va stylesheet'lar kabi statik kontentni saqlaydigan va yetkazib beradigan serverlar tarmog'i. Kontentni foydalanuvchilarga geografik jihatdan yaqinlashtirish orqali CDN'lar latency'ni kamaytiradi va yetkazib berishni tezlashtiradi.

Bu turli shaharlarda mahalliy omborlarga ega bo'lishga o'xshaydi — mijozlar uzoqdan jo'natiladigan posilkalarni kutib o'tirishlari shart bo'lmaydi.

CDN'dan quyidagi hollarda foydalanasiz:

• Media'ga boy saytlar (videolar, rasmlar, katta fayllar)

• Tez yuklanish vaqtiga muhtoj global foydalanuvchilar

Sharding nima va u scalability'ga qanday yordam beradi?

Sharding — ma'lumotlar bazasini shard'lar deb ataladigan kichikroq, mustaqil qismlarga ajratish; har bir shard ma'lumotlarning bir qismini saqlaydi va bo'linish odatda user ID kabi kalitga asoslanadi. Bu scaling'ni osonlashtiradi, chunki hech bir ma'lumotlar bazasi butun yuklamani yolg'iz ko'tarishi shart emas. Buning o'rniga har bir shard ma'lumotlarning faqat bir qismi uchun javob beradi.

Amalda Uber kabi ride-sharing ilovasi ma'lumotlarni shaharlar bo'yicha shard qilishi mumkin, shunda har bir hudud faqat mahalliy safarlar bilan ishlaydi. Bu foydalanuvchilar bazasi butun dunyo bo'ylab o'sgan sari ham query'larni tez saqlaydi.

SQL yoki NoSQL'ni qachon tanlagan bo'lardingiz?

SQL va NoSQL o'rtasidagi tanlov ma'lumotlaringiz va tizim talablaringizga bog'liq.

• SQL (masalan, PostgreSQL, MySQL): Strukturalangan ma'lumotlar, murakkab query'lar va har doim to'g'ri bo'lishi shart bo'lgan transaction'lar uchun eng yaxshi tanlov. Yaxshi misol — aniqlik va consistency hal qiluvchi ahamiyatga ega bo'lgan bank ledger'lari.

• NoSQL (masalan, MongoDB, Cassandra): Strukturalanmagan yoki yarim strukturalangan ma'lumotlar, ulkan miqyos va tez yozish amallari uchun eng yaxshi tanlov. Ijtimoiy ilovalar jadvallarga tartibli joylashmaydigan moslashuvchan foydalanuvchi profillari yoki log'larni saqlash uchun ko'pincha NoSQL'dan foydalanadi.

Umumiy qoida sifatida, strong consistency va relational ma'lumotlar kerak bo'lganda SQL'dan, moslashuvchanlik va scalability kerak bo'lganda esa NoSQL'dan foydalaning.

Replication konsepsiyasini va uning turlarini (Master-Slave, Master-Master) tushuntiring.

Replication — tizim ishonchliroq bo'lishi va ko'proq o'qish amallarini ko'tara olishi uchun ma'lumotlarni bir nechta serverga nusxalash. U fault tolerance va scalability'ni yaxshilashga yordam beradi, ammo murakkablik jihatidan trade-off'larni keltirib chiqarishi mumkin.

Replication turlari:

• Master-Slave: Bitta server (master) barcha yozish amallarini bajaradi, bir yoki bir nechta slave esa o'qish uchun nusxalarni saqlaydi. Bu tuzilma oddiy va backup'lar uchun juda qulay. Masalan, MySQL ko'pincha shu modeldan foydalanadi.

• Master-Master: Bir nechta server yozish amallarini bajara oladi va ular bir-biri bilan sinxronlanadi. Bu murakkabroq, chunki conflict'lar yuz berishi mumkin, lekin Google Spanner kabi low-latency yozishni talab qiladigan global ilovalar uchun kuchli yechim.

Eventual consistency va strong consistency nima?

Consistency turli serverlardagi ma'lumotlar qanchalik dolzarb ekanini tavsiflaydi.

• Strong consistency: Har bir o'qish eng so'nggi yozilgan qiymatni qaytaradi. Bu aniqlikni kafolatlaydi, lekin availability'ni pasaytirishi mumkin. Masalan, birja savdo platformasi foydalanuvchilar o'zida bor aksiyalardan ortig'ini sotib yubormasligi uchun strong consistency'dan foydalanishi shart.

• Eventual consistency: O'qishlar biroz eskirgan ma'lumotni qaytarishi mumkin, ammo barcha nusxalar oxir-oqibat bir xil holatga keladi. Bu availability va unumdorlikni oshiradi. Masalan, Amazon DynamoDB xarid savatlari uchun eventual consistency'dan foydalanadi, chunki u yerda kichik kechikish maqbul.

Asosiy g'oya shundaki, strong consistency to'g'rilikni darhol kafolatlaydi, eventual consistency esa uptime va tezlikni ustun qo'yadi.

Asoslar ko'rib chiqilgach, intervyu oluvchilar endi real tizimlarni qurish uchun asosiy tushunchalarni qanday birlashtirishingizni ko'rishni xohlashadi. Bu savollar ilovalarni bosim ostida ishlab turishini ta'minlaydigan “yelim”ni qanchalik tushunishingizni hamda unumdorlik, reliability va scalability o'rtasida muvozanat saqlash uchun qiladigan tanlovlaringizni sinaydi.

O'rta darajadagi system design intervyu savollari

Rate limiter'ni qanday loyihalagan bo'lardingiz?

Rate limiter mijoz ma'lum vaqt ichida qancha so'rov yubora olishini nazorat qiladi va tizimlarni spam yoki denial-of-service hujumlari kabi suiiste'mollardan himoya qiladi.

Keng tarqalgan yondashuvlar:

• Token bucket: Token'lar belgilangan tezlikda qo'shiladi. Har bir so'rov bitta token sarflaydi; agar token qolmasa, so'rov bloklanadi.

• Sliding window: Vaqt oynasi ichidagi so'nggi so'rovlarni kuzatadi va juda qisqa vaqtda juda ko'p so'rov kelsa, ularni bloklaydi.

Amalda API'lar rate limiting'ni ko'pincha middleware'da, so'rovlarni distributed tarzda sanash uchun Redis yordamida amalga oshiradi. Limitlar oshib ketganda so'rovlar odatda 429 Too Many Requests xatosini qaytaradi.

Message queue'lar (masalan, Kafka, RabbitMQ) system design'da qanday yordam beradi?

Message queue'lar servislarga asinxron tarzda aloqa qilish imkonini beradi. Bir-birini to'g'ridan-to'g'ri chaqirish o'rniga, bitta servis queue'ga xabar yuboradi, boshqa servis esa uni keyinroq qayta ishlaydi. Mashhur queue servislari:

• Kafka: Yuqori throughput'li event stream'lar uchun optimallashtirilgan (masalan, log'lar, analytics)

• RabbitMQ: Ishonchli task queue'lar va kafolatlangan yetkazib berish uchun juda mos

Masalan, e-commerce'da buyurtmani tasdiqlash xabarini queue'ga qo'yish mumkin, shunda to'lov servisi sekin ishlasa ham checkout jarayoni bloklanib qolmaydi. Bu tizimlarni Black Friday savdolari paytidagi kabi og'ir yuklama ostida bardoshliroq qiladi.

Distributed lock qanday ishlashini tushuntiring.

Distributed lock ko'plab serverlardan iborat tizimda bir vaqtning o'zida faqat bitta process muhim amalni bajara olishini ta'minlaydi. Masalan, bank ilovasida distributed lock ikkita serverning bir vaqtda bitta hisobdan pul yechib olishining oldini olishi mumkin.

Distributed lock'larni amalga oshirish va race condition'larning oldini olish uchun odatda Redis (expiration bilan SETNX'dan foydalanib) va ZooKeeper kabi vositalar ishlatiladi.

Cache stampede yoki cache avalanche'ning oldini qanday olasiz?

Cache stampede ko'plab so'rovlar bir vaqtning o'zida muddati tugagan keshga urilib, ma'lumotlar bazasini ortiqcha yuklaganda yuz beradi. Buning oldini olish uchun quyidagilarni qilishingiz mumkin:

• Early expiration'dan foydalaning (muddati tugashidan oldin yangilang).

• Faqat bitta so'rov keshni yangilashi uchun mutex lock'lar bilan request coalescing'ni qo'llang.

• Mashhur kalitlarni muddati tugashidan oldin pre-warm qiling.

Cache avalanche ko'plab kesh yozuvlarining muddati bir vaqtda tugab, yuklama keskin oshib ketganda yuz beradi. Buni tuzatish uchun quyidagilarni qilishingiz mumkin:

• Tasodifiy expiration buferlari bilan staggered TTL'lardan foydalaning.

• Kesh ma'lumotlar bazasi bilan birga yangilanib borishi uchun write-through caching'ni qo'llang.

Distributed system'larda sinxron va asinxron aloqa o'rtasidagi farq nima?

Sinxron aloqada yuboruvchi javobni kutadi. Bu oddiy, ammo bitta servis sekin ishlasa, cascading failure'larga olib kelishi mumkin. Keng tarqalgan misol — microservice'lar o'rtasidagi HTTP so'rov. Bunga qarama-qarshi o'laroq,

asinxron aloqada yuboruvchi xabarni queue'ga yoki event stream'ga qo'shadi va ishini davom ettiradi. Bu bardoshliroq va yaxshiroq scale qilinadi, ammo uni end-to-end kuzatish qiyinroq.

Asinxron aloqaning amaliy misoli — Spotify playlist'ni yangilayotganda, downstream servislar band bo'lsa ham, ilova javob berishda davom etishi.

Katta tizimlarda database schema migration'larini qanday boshqarasiz?

Katta tizimlarda schema o'zgarishlarini downtime'siz birdaniga amalga oshirib bo'lmaydi. Eng yaxshi amaliyotlar quyidagilarni o'z ichiga oladi:

• O'zgarishlarni version control bilan kuzatish uchun Flyway yoki Liquibase kabi vositalardan foydalanish

• O'zgarishlarni backward-compatible tarzda joriy etish (masalan, eski ustunlarni olib tashlashdan oldin yangilarini qo'shish)

• Zero downtime uchun blue-green deployment'lar yoki bosqichma-bosqich rollout'lardan foydalanish

API gateway'ni qanday loyihalagan bo'lardingiz?

API gateway — microservice'lar oldida turadigan, mijozlar uchun yagona kirish nuqtasi. U odatda quyidagilarni bajaradi:

• Authentication va authorization

• Rate limiting

• So'rovlarni routing va aggregation qilish

• So'rov va javoblarni transformatsiya qilish

• Load balancing

API gateway'ni loyihalashda e'tiborga olinadigan asosiy jihatlar:

• Unumdorlik: past latency bilan yuqori throughput'ni ko'tarish.

• Availability: single point of failure'lardan qochish.

• Xavfsizlik: uzatilayotgan maxfiy ma'lumotlarni himoya qilish.

• Observability: monitoring uchun metric'larni yig'ish.

Loyihalashdan so'ng deploy qilish managed service'da (masalan, AWS API Gateway yoki Azure API Management) yoki self-hosted tarzda (NGINX, Traefik yoki Envoy kabi vositalar yordamida) amalga oshirilishi mumkin.

Reverse proxy'larning rolini tushuntiring.

Reverse proxy mijozlar va backend serverlar o'rtasida joylashadi. U quyidagilarni bajara oladi:

• SSL/TLS ulanishlarini terminate qilish

• Keshlash va compression'ni amalga oshirish

• So'rovlarni serverlar bo'ylab load balance qilish

• Xavfsizlik uchun backend tafsilotlarini yashirish

Reverse proxy'larga misollar — Nginx va HAProxy.

Microservice'lar uchun logging va monitoring tizimini qanday loyihalagan bo'lardingiz?

Distributed logging va monitoring tizimi ko'plab servislardan ma'lumot yig'ib, uni amaliy xulosalarga aylantirishi kerak.

Logging arxitekturasi:

• Yig'ish: Har bir servis strukturalangan log'larni yozadi (masalan, JSON).

• Jo'natish: Fluentd yoki Filebeat kabi log shipper'lar log'larni aggregator'ga yuboradi.

• Saqlash: Elasticsearch yoki AWS CloudWatch kabi markazlashgan global fayl saqlash tizimi.

• Tahlil: Kibana yoki Grafana kabi query va vizualizatsiya vositalari.

Monitoring layer'lari:

• Infratuzilma: CPU, xotira, disk va tarmoqdan foydalanish.

• Ilova: So'rovlar chastotasi, javob vaqtlari, error rate'lar.

• Biznes: Foydalanuvchilar ro'yxatdan o'tishi, transaction hajmlari va daromad kabi metric'lar.

Notification tizimini (masalan, push, SMS, email) qanday loyihalashingizni tushuntiring.

Notification tizimi yangilanishlarni push, SMS yoki email kabi bir nechta kanal orqali yetkazib beradi.

Asosiy qismlar:

• Notification service: Markaziy koordinator

• Message queue: Katta hajmdagi bildirishnomalar uchun bufer

• Channel handler'lar: Har bir kanal uchun ixtisoslashgan processor'lar

• Template engine: Shaxsiylashtirilgan kontent yaratadi

• Delivery tracking: Muvaffaqiyatli va muvaffaqiyatsiz yetkazishlar ulushini kuzatadi

Bu tizimni qurayotganda uni bosqichlar bo'yicha o'ylang:

1. Ingestion: Kiruvchi event'larni ishonchli qabul qilish va buferlash uchun queue'dan (Kafka, RabbitMQ) foydalaning.

2. Qayta ishlash: Worker'lar queue'dagi event'larni iste'mol qiladi, kerak bo'lsa ularni qo'shimcha ma'lumotlar bilan boyitadi va to'g'ri provider orqali jo'natadi (masalan, SMS uchun Twilio).

3. Yetkazib berish kafolatlari: Ishonchli va shaxsiylashtirilgan yetkazib berishni ta'minlash uchun retry'larni joriy qiling, rate limit'larni qo'llang va foydalanuvchi tanlovlarini hurmat qiling.

Asosiy konsepsiyalarni birlashtirib, ularni real muammolarga qo'llash muhim, ammo intervyu oluvchilar katta miqyosdagi murakkablikni qanday boshqarishingizni ham ko'rishni xohlashadi. Ular tizimlar bosim ostida o'zini qanday tutishini, unumdorlikni qanday saqlab qolishingizni va odamlar har kuni tayanadigan tizimlar bilan qanchalik yaxshi ishlay olishingizni tushunishingizni sinashadi.

Yuqori darajadagi system design intervyu savollari

Hamkorlikda hujjat tahrirlash tizimini (Google Drive yoki Dropbox kabi) qanday loyihalagan bo'lardingiz?

Hamkorlikdagi muharrir bir nechta foydalanuvchiga bitta hujjatni real vaqtda conflict'larsiz tahrirlash imkonini berishi kerak. Asosiy qismlar:

• Conflict resolution: Bir vaqtdagi tahrirlar bir-birining ustidan yozib yubormasligi uchun Operational Transformation (OT) yoki Conflict-free Replicated Data Types (CRDTs)'dan foydalaning.

• Real vaqtdagi yangilanishlar: Mijozlar va serverlar o'rtasida low-latency sinxronlash uchun WebSocket'lardan foydalaning.

• Backend koordinatsiyasi: Redis kabi pub/sub tizimi yangilanishlarni barcha ulangan foydalanuvchilarga tarqatadi.

• Saqlash: Scalability uchun document ID bo'yicha shard qilingan PostgreSQL kabi relational ma'lumotlar bazasidan foydalaning.

URL qisqartirish servisini (bit.ly kabi) qanday loyihalagan bo'lardingiz?

URL shortener uzun havolalarni qisqa, ulashish oson kalitlarga moslaydi va milliardlab lookup'larni uddalaydi. Uni loyihalash quyidagilarni o'z ichiga oladi:

• Kalit generatsiyasi: Auto-increment ID'ning Base62 encoding'idan foydalaning yoki unikallik uchun hash'lar yarating.

• Saqlash: Tez yozish va o'qish uchun Cassandra kabi distributed NoSQL ma'lumotlar bazasidan foydalaning.

• Unumdorlik: Ma'lumotlar bazasidagi lookup'larni kamaytirish uchun mashhur URL'larni Redis'da keshlang.

• Qo'shimchalar: Analytics ma'lumotlarini yig'ing (bosishlar, referrer'lar, geolokatsiya).

Ijtimoiy tarmoq feed tizimini (masalan, Facebook newsfeed, Twitter timeline) qanday loyihalagan bo'lardingiz?

Feed'lar katta miqyosda real vaqtdagi yangilanishlarni ranking bilan birlashtirishi kerak. Uni loyihalash quyidagilarni o'z ichiga oladi:

• Fan-out on write**:** Yangi post'larni to'g'ridan-to'g'ri follower'larning feed'lariga push qiling. Faol foydalanuvchilar uchun tez, lekin millionlab follower'larga ega mashhurlar uchun qimmat.

• Fan-out on read**:** Post'larni markazlashgan holda saqlang va foydalanuvchi feed'ni ochganda uni quring. Saqlash joyini tejaydi, lekin query yuklamasini oshiradi.

• Ranking: Post'larni faqat yangiligiga qarab emas, balki relevance bo'yicha tartiblash uchun ML modellaridan foydalaning.

• Saqlash va keshlash: Qaynoq feed'lar uchun shard qilingan ma'lumotlar bazalari va in-memory keshlardan foydalaning.

Qidiruv autocomplete tizimini qanday loyihalagan bo'lardingiz?

Autocomplete foydalanuvchi yozayotgan paytda natijalarni taklif qiladi, shuning uchun u tez ishlashi va doimiy yangilanib turishi kerak. Uni loyihalashda e'tiborga olinadigan asosiy qismlar:

• Ma'lumotlar tuzilmasi: Prefix'larni samarali saqlash uchun Trie yoki inverted index'dan foydalaning.

• Qidiruv tizimi: Elasticsearch kabi tizimlar prefix bo'yicha mosliklarni index qilib, ularni tez qaytara oladi.

• Keshlash: Low-latency lookup'lar uchun keng tarqalgan prefix'larni Redis'da saqlang.

• Xatolarni boshqarish: Imlo xatolarini hisobga olish uchun fuzzy matching'ni qo'llang (masalan, Levenshtein distance).

To'lovlarni qayta ishlash tizimini (Stripe/PayPal kabi) qanday loyihalaysiz?

To'lovlar xavfsizlik, reliability va regulatory compliance'ni talab qiladi. To'lov tizimini qurish quyidagilarni qamrab oladi:

• Microservice'lar: Authentication, transaction'larni qayta ishlash, fraud detection va bildirishnomalar uchun alohida servislar.

• Asinxron workflow'lar: Takroriy to'lovlarning oldini olish uchun retry'lar va idempotency maqsadida queue'lardan foydalaning.

• Compliance: PCI standartlariga amal qiling va maxfiy ma'lumotlarni shifrlang.

• Integratsiya: API'lar orqali banklar va karta tarmoqlari bilan ulaning.

• Idempotency: Retry'lar foydalanuvchilardan ikki marta pul yechib olmasligini ta'minlang.

E-commerce checkout tizimini qanday loyihalagan bo'lardingiz?

Checkout — o'ta muhim jarayon bo'lib, u ham consistent, ham bardoshli bo'lishi kerak. Uni loyihalash quyidagilarni talab qiladi:

• Atomic operation'lar: Savat, to'lov va inventar o'zaro mos holatda qolishini ta'minlash uchun saga pattern'lari yoki two-phase commit (2PC)'dan foydalaning.

• Queue'lar: Buyurtmani bajarish ishlarini (yetkazib berish, email'lar) async worker'larga o'tkazing.

• Inventory locking: Ortiqcha sotib yubormaslik uchun checkout paytida tovarni vaqtincha band qilib qo'ying.

Real vaqtdagi chat tizimini (WhatsApp/Slack kabi) qanday loyihalaysiz?

Global chat servislari har kuni milliardlab xabarlarni qayta ishlaydi va shu bilan birga bir zumda yetkazib berish, suhbatlar tarixi va multimedia qo'llab-quvvatlanishini ta'minlaydi. Arxitektura quyidagilarni o'z ichiga oladi:

• Transport: Doimiy, ikki tomonlama aloqa uchun WebSocket'lar.

• Saqlash: Xabarlarni distributed storage'ga yozing (masalan, time-series ma'lumotlar uchun Cassandra).

• Guruh chatlari: Xabarlarni bir nechta foydalanuvchiga tarqatish uchun pub/sub tizimlaridan foydalaning.

• Miqyos: Millionlab foydalanuvchiga ega chat xonalari uchun partitioning va sharding'dan foydalaning.

• Xavfsizlik: Maxfiylik uchun end-to-end encryption.

Tavsiyalar tizimini (masalan, Netflix, Amazon) qanday loyihalaysiz?

Tavsiyalar tizimlari mos elementlarni taklif qilish uchun foydalanuvchi xatti-harakatlari va kontent atributlarini tahlil qiladi, bu esa engagement va daromadga bevosita ta'sir qiladi. Bu ehtiyojni qondiradigan tizimni loyihalash quyidagilarni talab qiladi:

• Algoritmlar: Collaborative filtering (o'xshash foydalanuvchilar/elementlar) yoki content-based modellar (element atributlari).

• Batch layer: Spark yoki Hadoop yordamida tarixiy ma'lumotlar asosida offline training.

• Real-time layer: Yangi faollik asosida tavsiyalarni Kafka stream'lari bilan yangilash.

• Serving layer: Tavsiyalarni keshlash bilan ishlaydigan tezkor API orqali taqdim etish.

Video streaming servisini (YouTube/Netflix kabi) qanday loyihalaysiz?

Video streaming platformalari ulkan hajmdagi video kontentni, global tarqatishni va millionlab bir vaqtdagi tomoshabinlarni boshqaradi, shu bilan birga yuqori sifat va minimal buffering'ni saqlab qoladi. U saqlash, yetkazib berish va adaptive playback o'rtasida muvozanatni topishi kerak. Uni loyihalash quyidagilarni o'z ichiga oladi:

• Encoding: Videolarni bir nechta format va bitrate'larga transcode qiling.

• Saqlash: Videolarni object store'larda (masalan, S3), metadata'ni esa shard qilingan ma'lumotlar bazalarida saqlang.

• Yetkazib berish: Global tarqatish uchun CDN'lardan foydalaning.

• Adaptive playback: Video sifatini bandwidth'ga qarab moslashtirish uchun HLS yoki MPEG-DASH'dan foydalaning.

Ride-sharing ilovasi (Uber/Lyft) backend'ini qanday loyihalagan bo'lardingiz?

Ride-sharing platformalari marshrutlar, narxlash va resurslarni taqsimlashni optimallashtirgan holda millionlab haydovchi va yo'lovchilarni real vaqtda muvofiqlashtiradi. Ride-sharing platformasi arxitekturasini qurish quyidagilarni o'z ichiga oladi:

• Geospatial indexing: Yaqin atrofdagi haydovchilarni qidirish uchun Quadtree'lar yoki GeoHash kabi ma'lumotlar tuzilmalaridan foydalaning.

• Matching service: Masofa, ETA va surge pricing'ni hisobga olgan holda yo'lovchilarni haydovchilar bilan real vaqtda moslang.

• Xabar almashish: Safar yangilanishlari uchun WebSocket'lar yoki push notification'lardan foydalaning.

• Scalability: Mahalliy unumdorlik uchun shahar yoki hudud bo'yicha shard qiling.

Texnik intervyulardan tashqari, noaniqlik va to'liq bo'lmagan ma'lumotlarni o'z ichiga olgan scenario'ga asoslangan savollarga ham duch kelishingiz mumkin. Intervyu oluvchilar ular orqali noaniqlik bilan qanday ishlashingizni — aniqlashtiruvchi savollar berasizmi, oqilona taxminlar qilasizmi va yangi cheklovlar paydo bo'lgan sari dizayningizni moslashtirasizmi — ko'rishni xohlashadi. Ular nafaqat texnik chuqurligingizni, balki qarorlarni yo'naltirish, trade-off'larni tortish va xatolardan qochish uchun o'tmishdagi tajribangizga qanday tayanishingizni ham tushunishni xohlashadi.

Bu savollar ko'pincha texnik, mahsulot va muloqot jihatlarini aralashtiradi. Ular odatda quyidagi bir yoki bir nechta pattern'ga mos keladi:

• Noaniq talablar: Masalan, “Foydalanuvchilar o'rtasida xabar almashishni boshqaradigan tizim loyihalang. Kompaniya hali bu WhatsApp kabi real vaqtda yoki email kabi ko'proq asinxron bo'lishi kerakligini hal qilmagan. Bunga qanday yondashgan bo'lardingiz?”

• O'zgaruvchan cheklovlar: Masalan, “Siz kontent tavsiyalari tizimini loyihalagansiz. Endi dataset har uch oyda ikki baravar ko'payishini va latency talablari qat'iylashishini tasavvur qiling. Dizayningiz qanday moslashadi?”

• Trade-off qarorlari: Masalan, “Aytaylik, siz API rate-limiting tizimini loyihalayapsiz. Mahsulot jamoangiz power user'lar uchun moslashuvchanlikni xohlaydi, infra jamoasi esa qat'iy cheklovni talab qiladi. Bu ehtiyojlarni qanday muvozanatlagan bo'lardingiz?”

• O'tmishdagi tajribani tahlil qilish: Masalan, “Dastlabki taxminlaringiz o'zini oqlamagani sababli tizimni qayta loyihalash yoki refactoring qilishga to'g'ri kelgan vaziyat haqida gapirib bering. Muammoni qanday aniqladingiz va uni qanday tuzatdingiz?”

Bu savollarni nazorat qila olmasligingiz mumkin, lekin javobingizni nazorat qila olasiz. Scenario'ga asoslangan savollarga javob berishda quyidagi tartibga amal qilishingiz mumkin:

1. Noaniqlikni aniqlashtiring: Avvalo savolni to'liq tushunganingizga ishonch hosil qiling. Agar miqyos, latency, foydalanuvchilar, reliability va boshqa cheklovlar haqida ma'lumot berilmagan bo'lsa, ular bo'yicha aniqlashtiruvchi savollar bering.

2. Taxminlaringizni ayting: Tafsilotlar yetishmaganda taxminlaringizni ochiq ayting. Bu intervyu oluvchiga qarorlaringiz ortidagi mantiqni ko'rsatadi.

3. Yondashuvingizni tartibga soling: To'g'ridan-to'g'ri tafsilotlarga sho'ng'ish istagiga berilmang. Qismlar, data flow va ehtimoliy bottleneck'larni belgilab, umumiy ko'rinishdan boshlang. Poydevor aniq bo'lgach, keshlash, ma'lumotlar bazalari yoki xabar almashish tizimlari kabi tafsilotlarga o'ting.

4. Trade-off'larni muhokama qiling: Yodlangan yechimlarni aytib berish o'rniga variantlarni tortib ko'rayotganingizni ko'rsating. Trade-off'larni muhokama qilish intervyu oluvchiga fikrlash jarayoningizni kuzatishga yordam beradi va tanqidiy fikrlashingizni namoyon etadi.

5. O'tmishdagi tajribangizga bog'lang: Agar shunga o'xshash narsa qurgan bo'lsangiz, o'sha tajribadan foydalaning. Javobingiz real hayotga asoslangan bo'lishi uchun olgan saboqlaringiz, qabul qilingan asosiy qarorlar va amaliy natijalar bilan o'rtoqlashing.

6. Aniq muloqot qiling: Yaqqol tasavvur hosil qilishga yordam berish uchun diagrammalar yoki mental modellardan foydalaning. “Uchta layer'ni tasavvur qiling: mijoz, API gateway va backend servislar” kabi gap fikrlaringizni intervyu oluvchiga aniq yetkazishga yordam beradi. Shuningdek, yakunlashdan oldin muhokama qilgan barcha fikrlaringizni xulosalashni unutmang.

Ushbu tartibga amal qilib, siz nafaqat texnik bilimingizni, balki muammolarni hal qilishga yondashuvingizni, muloqot ko'nikmalaringizni va noaniqlik sharoitida qaror qabul qila olishingizni ham namoyon etasiz.

Keyingi qadamlar

Yodda tuting: system design intervyulari bitta to'g'ri javobga ega testlar emas, balki suhbatlardir. Intervyu oluvchilar murakkab muammolar ustida qanday fikr yuritishingizni, trade-off'larni qanday tortishingizni va mulohazalaringizni qanchalik aniq yetkazishingizni ko'rishni xohlashadi. Fikrlash jarayoningizni ovoz chiqarib tushuntirishni, aniqlashtiruvchi savollar berishni va turli yondashuvlarning afzallik va kamchiliklarini muhokama qilishni mashq qiling.

Intervyu yaqinlashgan sari tizim konsepsiyalariga kuniga atigi 30 daqiqa ajratish ham katta farq qilishi mumkin. Tayyorgarlik qiziqarli bo'lib qolishi uchun turli usullarni bemalol almashtirib turing:

• O'zingizni sinash va asosiy konsepsiyalarni mustahkamlash uchun system design flashcard'laridan foydalaning.

• Muayyan mavzular haqida ko'proq bilish va ko'plab tizimlarda uchraydigan pattern'larni tushunish uchun system design roadmap'ini o'rganing.

Muntazam mashq va mulohaza orqali har qanday system design intervyu masalasiga aniqlik va xotirjamlik bilan yondashish uchun ishonch va ko'nikmalarga ega bo'lasiz.