Problem: boş lövhə
Sizə "bildiriş servisi dizayn edin" kimi bir cümlə və qırx beş dəqiqə verilir. Bir çox namizəd iki şeydən birini edir: ya dərhal Kafka və Redis yazılmış qutular çəkməyə başlayır, ya da məsələ açıq olduğu üçün donub qalır. Hər ikisi eyni səbəbdən uğursuz olur: prosesləri yoxdur. Müsahibə aparan tək düzgün arxitekturanı axtarmır. O, qeyri-müəyyənliyi necə azaltdığınıza, rəqəmlərlə necə fikirləşdiyinizə, seçim etdiyinizə və nəyin pozula biləcəyini görüb-görmədiyinizə baxır.
Eyni bacarıqlar müsahibədən kənarda da vacibdir. İşdəki dizayn review-u cavabların nəticəsi olan system design müsahibəsidir. Təkrarlamaq asan olan metod sizi sakit saxlayır və söhbəti faydalı edir.
Səkkiz addımlı metod
1. Tələbləri və əhatəni aydınlaşdırın
Çəkməzdən əvvəl sual verin. Funksional tələbləri (sistem nə edir) qeyri-funksionallardan (gecikmə, əlçatanlıq, consistency, davamlılıq, təhlükəsizlik) ayırın. Nəyin kənarda qaldığını razılaşdırın. Bildiriş servisi üçün faydalı suallar: hansı kanallar (email, push, SMS), çatdırılma vaxta həssasdırmı, bildiriş heç vaxt itməməlidirmi, iki dəfə göndərilə bilərmi, hadisə başına neçə alıcı var?
2. Təxmini hesablayın
Dəqiqlik yox, tərtib (order of magnitude) lazımdır. Fərziyyələri yazın və işarələyin. Məsələn: 5 milyon istifadəçi, gündə hər birinə 2 bildiriş, yəni gündə 10 milyon, orta hesabla saniyədə təxminən 115. Pik üçün 10 qat fərz etsək, saniyədə təxminən 1 200. Məqsəd onlarla, minlərlə, yoxsa milyonlarla sorğu üçün dizayn etdiyinizi və storage-in, yoxsa throughput-un üstün olacağını bilməkdir.
3. API və əsas entity-ləri müəyyənləşdirin
İki-üç endpoint və ya hadisəni və əsas data entity-lərini eskiz edin. Bu, giriş və çıxışlar barədə dəqiqlik tələb edir və çatışmayan tələbləri erkən üzə çıxarır.
POST /v1/notifications
{ "userId": "u-42", "template": "order-shipped",
"channel": "push", "idempotencyKey": "evt-9981" }
-> 202 { "id": "n-1001", "status": "QUEUED" }
Entities: Notification(id, userId, channel, status, createdAt)
Preference(userId, channel, enabled)4. High-level dizayn çəkin
Tələbləri ödəyən ən sadə variantdan başlayın və komponenti yalnız tələb olanda əlavə edin.
Client -> API -> Queue -> Sender workers -> Provider (email/push)
| |
v v
Preferences DB Notification DB (status)Sorğu yolunu başdan sona izah edin, sonra hansı komponentlərin stateless, hansılarının state saxladığını deyin.
5. Risk olan yerdə dərinə gedin
Ən çətin və ya ən aktual bir-iki hissəni seçin: sıralama, dublikatlar, qaynar partition-lar, xarici provayderlərin rate limit-ləri, retry-lər. Müsahibə aparan çox vaxt sizi bura yönəldir. Hər yerdə səthi olmaq əvəzinə bir sahədə dərinlik göstərin. Bildirişlər üçün yaxşı dərin analiz at-least-once çatdırılma və idempotent göndərişdir; bu, idempotency pattern-ləri ilə bağlıdır.
6. Güzəştləri açıq müzakirə edin
Hər vacib seçim üçün alternativi və onu niyə seçmədiyinizi deyin: queue gecikmə və əməliyyat xərci əlavə edir, amma yük partlayışlarını udur; sinxron çağırışlar sadədir, amma əlçatanlığı provayderə bağlayır. "X seçdim, çünki Y tələbi Z xərcindən vacibdir" ifadəsi istənilən texnologiya adından güclüdür.
7. Nasazlıq rejimlərini əhatə edin
Hər komponent üçün "nə pozulur?" deyə soruşun: provayder işləmir, queue dolub, worker göndərişin ortasında çöküb, verilənlər bazası failover edir. Timeout, backoff ilə retry, dead-letter idarəsi, backpressure və azalmış rejimdə davranışı qeyd edin. Terminologiya üçün distributed systems failure məqaləsinə baxın.
8. Yekunlaşdırın və növbəti addımları deyin
Dizaynı bir neçə cümlə ilə təkrarlayın, məlum zəifliklərini sadalayın və nəyi ölçəcəyinizi və ya növbəti nəyi quracağınızı deyin: observability, yük testləri, təhlükəsizlik review-u, xərc.
Müsahibə aparanlar adətən nəyə qulaq asır
Şirkətlərdən asılı olmayaraq siqnallar oxşar olur: qurmazdan əvvəl soruşurmu? Təxmini rəqəmlərlə mühakimə yürüdə bilirmi? Tələbi ödəyən ən sadə dizaynı seçirmi? Sevimli alətini müdafiə etmədən güzəşti izah edə bilirmi? Nasazlığı görürmü? Bunların heç biri əzbərlənmiş arxitekturalar tələb etmir. Onlar strukturlu düşünmə vərdişi tələb edir və təkrarlanan metodun təzyiq altında kömək etməsinin səbəbi də budur.
45 dəqiqəlik sessiya üçün vaxt bölgüsü
| Addım | Təxmini pay |
|---|---|
| Tələblər və hesablamalar | 10 dəqiqə |
| API və data | 5 dəqiqə |
| High-level dizayn | 10 dəqiqə |
| Dərin analiz | 12 dəqiqə |
| Güzəştlər, nasazlıqlar, yekun | 8 dəqiqə |
Bunu bələdçi kimi qəbul edin; müsahibə aparanın suallarına uyğunlaşın.
Kiçik nümunə: addımların bir yerdə işləməsi
"Qısa link servisi" üçün ilk iki dəqiqədə tələbləri soruşursunuz: redirect-lər sürətli olsun, link təxmin edilməsin, klik sayı lazımdır. Sonra təxmini rəqəmlər göstərir ki, sistem oxuma ağırlıqlıdır. Bu, cache qərarını əsaslandırır, sharding qərarını isə sonraya saxlayır. API-ni eskiz edirsiniz, sadə dizaynı çəkirsiniz, sonra kodun təkrarsızlığı və klik analitikasını dərin analiz üçün seçirsiniz. Bu axında texnologiya adı yalnız rəqəmlər və tələblər onu tələb edəndən sonra çəkilir.
Tez-tez edilən səhvlər
- Texnologiyaya tullanmaq. Throughput-u bilmədən Kafka demək, düşüncəni yox, pattern yadda saxlamağı göstərir.
- Hesablamanı atlamaq və ya dəqiq rəqəmlər uydurmaq. Yuvarlaq rəqəmlər işlədin, hesabı göstərin və fərziyyə olduğunu deyin.
- Defolt olaraq planetar miqyas üçün dizayn etmək. Həddindən artıq mühəndislik mühakimə qüsurudur. Sadədən başlayın və rəqəmlərin göstərdiyi yerdə miqyaslayın.
- Səssiz düşünmək. Müsahibə aparan yalnız eşitdiyini qiymətləndirə bilər. Mühakimənizi səsləndirin.
- Qeyri-funksional tələbləri nəzərə almamaq. Consistency və ya əlçatanlıq hədəfi olmayan dizaynı qiymətləndirmək olmur.
- Hər seçimi müdafiə etmək. Müsahibə aparan qüsur göstərirsə, qəbul edin və uyğunlaşın; yaxşı dizayn review-u belə görünür.
- Nasazlıq müzakirəsinin olmaması. Yalnız uğurlu ssenarini əhatə edən dizayn natamamdır.
Metodu işdə istifadə etmək
Dizayn review-unda eyni addımlar sənəd planına çevrilir: məqsədlər və qeyri-məqsədlər, miqyas fərziyyələri, API, data modeli, arxitektura, baxılan alternativlər, risklər, rollout planı. Qərarları ADR-də qeyd edin. Metod düşüncə alətidir, ssenari deyil; addım aktual deyilsə, bunu deyin və keçin.
Məşq planı
- Tanış məhsul seçin (çat tətbiqi, fayl yükləmə servisi, rate limiter).
- 45 dəqiqəlik taymer qoyun və ucadan danışın, ideal olaraq həmkarla və ya yazıya.
- Səkkiz addımı izləyin və fərziyyələri kağıza yazın.
- Sonra atladığınız və ya səthi keçdiyiniz nöqtələri sadalayın və araşdırın.
- Hər həftə fərqli məsələ ilə təkrarlayın, caching kimi yeni anlayışı öyrəndikdən sonra əvvəlkini yenidən işləyin.
- Bir nümunəni baştan sona öyrənin, məsələn URL shortener dizaynı, sonra yaddaşdan təkrarlayın.
Yoxlama siyahısı
- Tələblər aydınlaşdırılıb, əhatə məhduddur
- Fərziyyələri işarələnmiş hesablamalar
- API və entity-lər eskiz olunub
- Əvvəlcə ən sadə dizayn, komponentlər səbəblə əlavə olunur
- Bir-iki sahə dərindən araşdırılıb
- Güzəştlər alternativlərlə birlikdə deyilib
- Nasazlıq rejimləri əhatə olunub
- Yekun və növbəti addımlar
Növbəti addım
URL shortener nümunəsini nümunəvi cavab kimi keçin, bu dizaynlar real layihəyə çevriləndə solution architect-in nə etdiyini oxuyun və ya səviyyənizi bacarıq qiymətləndirməsi ilə yoxlayın.