Sistem tasarımı mülakatları bunaltıcı gelebilir, ancak öngörülebilir bir kalıba sahiptir. Başarı, her teknolojiyi bilmekten ziyade düşüncelerinizi net bir şekilde yapılandırmaya bağlıdır. Bu gönderi, URL kısaltıcılar ve gerçek zamanlı sohbet uygulamaları gibi klasik problemlere uygulayabileceğiniz sağlam bir çerçeve sunmakta ve mimari olgunluk ile derinlik sergilemenize yardımcı olmaktadır.
Adım 1: Gereksinimleri ve Kapsamı Netleştirin
Asla doğrudan mimariye atlamayın. Soru sınırlarını tanımlayarak başlayın. Bir URL kısaltıcı için şunları sorun: Analitiğe ihtiyacımız var mı? Beklenen trafik nedir? Bağlantı son kullanma süresi kritik mi? Bir sohbet uygulaması için netleştirin: 1'e 1 mi yoksa grup tabanlı mı? Çevrimdışı desteğe veya okundu bilgilerine ihtiyacımız var mı? Nicel kısıtlamalar çok önemlidir. URL kısaltıcının günde 100 milyon yazma ve 1 milyar okuma işlemi işlemesi gerektiğini varsayın. Sohbet uygulaması için, ortalama kullanıcı başına 50 mesajla 500.000 günlük aktif kullanıcı varsayın.
Adım 2: Yüksek Seviyeli Mimari Tasarım
Çekirdek bileşenleri taslaklayın. Her iki sistem tipik olarak İstemci, Yük Dengeleyici, Uygulama Sunucuları, Veri Katmanı ve olası bir Önbellek içerir.
URL Kısaltıcı Mimarisi
Çekirdek mantık basittir: Uzun bir URL'yi benzersiz bir kısa koda eşlemek. Yazma sırasında benzersiz bir kimlik oluşturun ve eşlemeyi saklayın. Okuma sırasında kimliği bulun ve yönlendirin. Kritik bir karar, kimlik oluşturma stratejisidir. Veritabanı otomatik artışı kullanmak basittir ancak darboğaz haline gelebilir. Daha iyi bir yaklaşım, dağıtık bir kimlik oluşturucu veya özetleme kullanmaktır. 7 karakterlik sınır içinde olası kısa URL sayısını en üst düzeye çıkarmak için base62 kodlamayı düşünün.
// Kısa URL Oluşturma Sahte Kodu
function generateShortCode(longUrl) {
// Seçenek 1: Veritabanı Sırası
id = db.get_next_id();
// Seçenek 2: Özet tabanlı (çakışma kontrolü ile)
hash = md5(longUrl).substring(0, 7);
if (db.exists(hash)) {
handle_collision(hash);
}
base62_code = to_base62(id);
return base62_code;
}
Sohbet Uygulaması Mimarisi
Sohbet gerçek zamanlıdır ve WebSocket bağlantıları veya uzun sorgulama gerektirir. Mimari, geçici durumu (çevrimiçi durumu) ve kalıcı durumu (mesajları) işlemelidir. Mesaj alımını teslimattan ayırmak için bir Mesaj Kuyruğu (Kafka, RabbitMQ) şarttır. Uygulama sunucusu, veritabanına doğrudan WebSocket bağlantıları tutmamalı; bunun yerine, dayanıklılık için mesajları bir NoSQL deposuna (Cassandra veya DynamoDB gibi) kalıcı hale getirmeli ve gerçek zamanlı itme için ayrı bir hizmet kullanmalıdır.
Adım 3: Veri Modeli ve Depolama Seçimi
Veri modelleri, erişim desenleriyle eşleşmelidir.
URL Kısaltıcı Veri Modeli
Okuma/yazma oranları dengeliyse, eşleme tablosu için ilişkisel bir veritabanı (MySQL) genellikle yeterlidir, ancak arama en sıcak yoldur. Sıcak kısa kodlar için Redis'i önbellek olarak kullanın. Tablo yapısı basittir: short_code (PK), long_url, created_at, creator_id. short_code özetine göre bölmek, düğümler arasında eşit dağılımı sağlar.
Sohbet Uygulaması Veri Modeli
Sohbet mesajları yalnızca ekleme yapılırdır. Yüksek verimli yazmalar için Cassandra gibi geniş sütunlu bir depo idealdir. Tabloyu, bir konuşma için son mesajların verimli bir şekilde alınmasına izin verecek şekilde tasarlayın.
CREATE TABLE messages (
conversation_id uuid,
message_timestamp timeuuid,
sender_id uuid,
content text,
PRIMARY KEY (conversation_id, message_timestamp)
) WITH CLUSTERING ORDER BY (message_timestamp DESC);
Adım 4: Ölçeklenebilirlik ve Darboğazlar
Tasarımınızın nerede kırıldığını belirleyin.
URL Kısaltıcıları Ölçeklendirme
Okumalar, yazmalardan genellikle 10-100 kat daha sıklıkta gerçekleşir. Önbellekleme zorunludur. Çok katmanlı bir önbellek uygulayın: Uygulama sunucusunda L1 bellek içi (Caffeine), L2 dağıtık (Redis). Sıcak anahtarlar için, ağ gecikmesini azaltmak için yerel önbellekleme kullanın. Kimlik oluşturucu bir darboğaz haline gelirse, uygulama sunucularına kimlik aralıkları ön ayıran dağıtık bir sıra oluşturucuya geçin.
Sohbet Uygulamalarını Ölçeklendirme
Darboğaz, WebSocket katmanıdır. Soket bağlantıları tutan uygulama sunucuları durumludur. Yatay ölçeklendirmeyi destekleyen bir bağlantı katmanı kullanın, olası olarak yapışkan oturum yük dengeleyici veya durumlu bir geçit hizmeti ile. Grup sohbetlerinde mesaj dağıtımı için, bir Pub/Sub sistemi (Kafka gibi) kullanın; burada bir grubun her üyesi kendi konusuna veya bölümüne abone olur. Bu, her kullanıcının mesajlarını almasını, diğerlerini engellemeden sağlar.
Adım 5: Ödünleşimler ve Kenar Durumları
Ödünleşimleri tartışarak derinlik sergileyin. URL kısaltıcılar için, benzersizlik garantisi ve performans arasındaki ödünleşimi tartışın. Bir özet çakışabilir; bir sıra benzersizdir ancak merkezi. Sohbet için, tutarlılık ve kullanılabilirlik arasındaki ödünleşimi tartışın. Bir sohbet uygulamasında, bir mesajın kaybedilmesi kötüdür, bu nedenle dayanıklılığı önceliklendirin. Ancak, varlık güncellemeleri (çevrimiçi/çevrimdışı) için güçlü tutarlılık gerekmez; TTL tabanlı bir önbellek ile nihai tutarlılık kabul edilebilir ve daha performanslıdır.
Sonuç
Sistem tasarımı mülakatları, ezberleme değil, yapılandırılmış problem çözmekle ilgilidir. Bu çerçeveyi izleyerek—gereksinimleri netleştirmek, yüksek seviyeli mimari tasarlamak, doğru veri modelini seçmek, ölçeklenebilirlik darboğazlarını belirlemek ve ödünleşimleri tartışmak—karmaşık tasarım sorularına güvenle yön verebilirsiniz. Bu metodolojiyi hem URL kısaltıcılar hem de sohbet uygulamalarına uygulamayı pratik edin ve herhangi bir sistem tasarımı zorluğunu ele almak için sezgi geliştireceksiniz.