Frontend Sistem Tasarımı Mülakatları: Belirsiz Sorudan Net Bir Plana

Frontend sistem tasarımı mülakatları zor görünebilir. “Paylaşımlı görev panosu tasarla” dendiğinde React, WebSocket, cache, API ve performans aynı anda akla gelir. Daha iyi başlangıç basittir: Teknoloji seçmeden önce kullanıcının ne yapması gerektiğini tanımlayın.

Kütüphanelerden önce ürün

Şunları sorun: Kullanıcı görev oluşturabilir, düzenleyebilir ve taşıyabilir mi? Pano paylaşımlı mı? Değişiklikler anlık mı görünmeli? Ekler ve çevrimdışı düzenleme kapsamda mı?

Varsayımı açıkça söyleyin: Kimliği doğrulanmış ekip üyeleri için web görev panosu tasarlıyorum. Kullanıcılar sütunları görür, görev oluşturur ve taşır; pano açıkken ekip arkadaşlarının değişikliklerini görür. Ekler ve offline düzenleme kapsam dışıdır.

Bu, “Jira’nın tamamını tasarla” yerine somut bir problem verir.

Fonksiyonel ve kalite gereksinimleri

Fonksiyonel gereksinimler davranışı anlatır: panoyu görüntüleme, görev taşıma, filtreleme ve ekip değişikliklerini görme. Gecikme, erişilebilirlik, güvenilirlik ve ölçeklenebilirlik mimariyi etkileyen kalite gereksinimleridir.

Görev taşınırken kullanıcı kartı sürükler, arayüz hemen güncellenir, istemci mutasyonu gönderir, sunucu kanonik durumu döner ve diğer kullanıcılara olay gider. İstek başarısız olursa durum geri alınır.

Veri modeli ve API sözleşmesi

İstemcinin görev kimliği, sütun, sıra ve sürüme ihtiyacı vardır. Güncelleme sözleşmesi columnId, position ve version taşıyabilir. Sunucu nihai görevi yeni sürümüyle döndürmelidir. Aynı görev paralel düzenlenirse last-write-wins veya eski sürümü reddedip yenileme isteme gibi bir kural açıklayın.

State'i sahiplik ve ömre göre seçin

Menü, sürükleme önizlemesi ve form değerleri yerel UI state'tir. Filtreler ve seçili pano URL state olmalıdır. Pano ve görevler gibi server state query cache'te tutulmalıdır. Realtime olayları ikinci kalıcı kopya oluşturmak yerine ilgili cache kaydını günceller veya geçersiz kılar.

Realtime ve optimistic update

Seyrek güncellemelerde polling yeterlidir. Tek yönlü sunucu güncellemelerinde Server-Sent Events uygundur. Presence, typing veya çift yönlü işbirliği WebSocket'i haklı çıkarabilir. Önce güncellik ihtiyacını, sonra teknolojiyi anlatın.

Optimistic update için snapshot alın, arayüzü yerelde güncelleyin, mutasyonu gönderin ve hata olursa snapshot'a dönün. Mutlu yol kadar hata yolunu da tasarlayın.

Frontend riskleri

• Uzun listeleri virtualize edin.
• Drag-and-drop'u klavye ve ekran okuyucu ile erişilebilir yapın.
• Loading, empty, izin reddi ve retry durumlarını tasarlayın.
• Değişen sıralarda index yerine stabil ID kullanın.
• Hassas içerik kaydetmeden yavaş etkileşimleri ve başarısız mutasyonları izleyin.

Mülakat cevap şablonu

1. Kullanıcıları, platformu ve değerli akışları netleştirin.
2. Kapsamı ve dışarıda kalanları söyleyin.
3. Fonksiyonel gereksinimleri yazın.
4. Kullanıcı akışlarına çevirin.
5. Veri modeli ve API sözleşmesini çıkarın.
6. State'i sahiplik ve ömre göre ayırın.
7. Performans, erişilebilirlik, güvenilirlik ve güvenliği ekleyin.
8. Trade-off'ları ve sonraki adımı açıklayın.

Sonuç

Frontend sistem tasarımı, kütüphane sayma yarışması değildir. Kullanıcının hedefiyle başlayın; state, API, rendering ve realtime kararları böylece net biçimde gerekçelenir.