C# .net Mülakat soruları serisi Kritik 5 Adet Soru ve cevapları

Bu sorunun doğru cevabı: LoadBalancer ✅

Soru Özeti:

• Bir Kubernetes kümesinde HTTP sunucusu çalıştıran birkaç Pod var.

• Bu Pod’lara dışarıdan, tek bir IP adresi üzerinden HTTP istekleri gönderilmek isteniyor.

• Pod’lardan bazıları kısa süreliğine ulaşılamaz olsa bile servis yanıt vermeye devam etmeli.

Seçeneklerin İncelemesi:

🔹 ClusterIP

• Yalnızca küme içinden erişim sağlar.

• Dışarıdan erişim sağlanamaz.

• ❌ Bu senaryo için uygun değil.

🔹 NodePort

• Dışarıdan erişime izin verir, ancak her Node’un IP adresi ve belirli bir port üzerinden erişim sağlanır.

• Yük dengeleme yapmaz.

• Dış erişim için karmaşıktır ve genellikle doğrudan kullanılmaz.

• ❌ Uygun değil.

🔹 LoadBalancer ✅

• Dışarıdan tek bir IP adresiyle erişim sağlar (bulut sağlayıcısı tarafından atanır).

• Pod’lar arasında yük dengeleme (load balancing) yapar.

• Bazı Pod’lar ulaşılamaz olsa bile servis çalışmaya devam eder.

• ✔️ Bu senaryo için en uygun seçenek budur.

🔹 ExternalName

• DNS adı ile dış kaynaklara yönlendirir.

• Pod’lara yönlendirme yapmaz, dış servislere yönlendirme içindir.

• ❌ Uygun değil.

🔹 Headless Service

• Yük dengeleme sağlamaz, her Pod’a doğrudan DNS ile erişim sağlar.

• Genellikle stateful servisler için kullanılır.

• ❌ Bu durumda uygun değil.

Doğru Cevap: Singleton Design Pattern

🔍 Singleton Deseni Nedir?

• Amaç: Bir sınıfın yalnızca bir örneğinin (instance) olmasını sağlamak ve bu örneğe küresel erişim sunmak.

• Kullanım Alanları:

  • Konfigürasyon sınıfları

  • Logger sınıfları

  • Cache yöneticileri

  • Database bağlantı yöneticileri (tek bağlantı kullanılacaksa)

🎯 Neden Doğru?

Bu desen tam olarak soruda anlatılan ihtiyacı karşılar:

• Sınıfın tek bir örneği olacak.

• Bu örnek, uygulamanın her yerinden erişilebilir olacak.

🔍 Diğer Seçenekler ve Neden Yanlış Oldukları:

• Adapter Design Pattern: Arayüzleri uyumlu hale getirir. İki uyumsuz sınıfı birlikte çalıştırmak için kullanılır. ❌

• Visitor Design Pattern: Nesne yapılarında yeni işlemler tanımlamak için kullanılır. ❌

• Template Design Pattern: İşlem adımlarını soyut sınıfta tanımlayıp, alt sınıfların detayları belirlemesini sağlar. ❌

• Observer Design Pattern: Bir nesnede değişiklik olduğunda bağlı olan diğer nesnelere haber verir. ❌

Creating a test user, calling the login function and checking the return values.

Açıklama:

Birim testleri (unit tests), bir kod parçasının (genellikle bir fonksiyon veya metot) küçük ve izole edilmiş birimini test etmeyi amaçlar. Login fonksiyonu için bir birim testi yazarken, fonksiyonun belirli girdilerle (test kullanıcı bilgileri gibi) doğru çıktıyı (başarı/başarısızlık durumu, oturum bilgisi döndürme vb.) üretip üretmediğini doğrulamak hedeflenir.

• Doğru Seçenek (Option 2): “Creating a test user, calling the login function and checking the return values.” Bu seçenek, birim testinin temel mantığını tanımlar. Test senaryosu için bir test kullanıcısı oluşturulur (veya kullanılır), login fonksiyonu çağrılır ve fonksiyonun döndürdüğü değerler (örneğin başarılı giriş için true, başarısız için false, oturum ID’si vb.) kontrol edilerek doğrulama yapılır. Fonksiyonun içindeki veritabanı gibi dış bağımlılıklar, gerçek bir birim testinde genellikle izole edilir veya taklit edilir (mocking) ki sadece fonksiyonun kendi mantığı test edilsin. Ancak seçenekler arasında, fonksiyonu doğrudan çağırıp dönüş değerlerini kontrol etmek birim testine en uygun yaklaşımdır.

Diğer Seçeneklerin Neden Uygun Olmadığı:

• Option 1: Creating a test user, logging in and confirming that a login session has been established in the database. Bu yaklaşım, bir veritabanı kontrolü içerdiği için birim testinden çok bir entegrasyon testine veya uçtan uca testine daha yakındır. Birim testleri genellikle harici bağımlılıkları (veritabanları gibi) test kapsamından çıkarır.

• Option 3: Test should be written in the actual code, not as a separate function. Test kodunun, test edilen üretim kodunun içine yazılması kötü bir yazılım geliştirme uygulamasıdır. Testler ayrı dosyalarda veya sınıflarda olmalı ve üretim kodundan bağımsız çalışmalıdır.

• Option 4: Logging in as a real user and observing the behaviours. Bu, otomatik bir birim testi değil, manuel bir test veya keşifsel test biçimidir. Birim testleri otomatik ve tekrarlanabilir olmalıdır.

• Option 5: Unit testing is unnecessary for login functionality as it can be visually confirmed. Login fonksiyonu gibi kritik bir işlevin birim testleri çok önemlidir. Görsel doğrulama yalnızca temel bir senaryoyu kapsayabilir, ancak farklı hata durumları, kenar durumları, girdi doğrulaması gibi mantıksal işlevsellik otomatik testlerle daha güvenilir bir şekilde doğrulanır. Ayrıca birim testleri, kodda yapılan değişikliklerin mevcut işlevselliği bozup bozmadığını (regresyonları) hızla tespit etmeye yardımcı olur.

Bu sorunun doğru cevabı:
✅ Break down the transaction management into smaller services and containerize each service using Docker. Use Kubernetes for orchestration.

❓ Soru Özeti:

• Bir firma, monolitik bir uygulamayı mikroservis mimarisine taşımak istiyor.

• Özellikle transaction management modülü, diğer modüllerle sıkı bağlı (tightly coupled) durumda.

• Amaç, her bir işlemin (transaction) izole (bağımsız) şekilde çalışmasını sağlamak.

• Transaction management modülü C# ile yazılmış.

🧠 Doğru Cevabın Gerekçesi:

✅ “Break down the transaction management into smaller services and containerize each service using Docker. Use Kubernetes for orchestration.”

Bu yaklaşım:

• Monolitik yapının parçalanmasını sağlar.

• Her bir küçük servis bağımsız şekilde çalışır, yani transaction isolation elde edilir.

• Docker ile her servis container olarak izole edilir.

• Kubernetes ise bu container’ları yönetmek ve ölçeklemek için kullanılır.

Yani, hem mikroservis mimarisine geçilmiş olur, hem de izole işlemler ve ölçeklenebilirlik gibi ihtiyaçlar karşılanır.

❌ Diğer Seçeneklerin Neden Uygun Olmadığı:

• “Re-write the transaction management module from scratch…”
  → Baştan yazmak maliyetli, zaman alıcı ve risklidir. Ayrıca bu sadece bir mikroservis sağlar, izolasyon sağlamaz.

• “Package each existing module into a set of lightweight processes…”
  → Her modül için benzersiz adres vermek çözüm sağlamaz. Modülerleştirme var ama izolasyon ve orchestrasyon eksik.

• “Create C# user-defined functions…”
  → Fonksiyon bazlı yaklaşım, mikroservis için yetersiz kalabilir. State management ve bağımlılık yönetimi zordur.

• “Use a serverless architecture…”
  → Uygun gibi görünebilir ancak transaction gibi durum (stateful) yönetimi gereken sistemler için serverless zor olabilir.

📌 Sonuç:

Docker + Kubernetes ile servisleri parçalamak, modern bir mikroservis mimarisi oluşturmak için en uygun, esnek ve ölçeklenebilir yöntemdir.
Bu yüzden doğru cevap:
✅ Break down the transaction management into smaller services and containerize each service using Docker. Use Kubernetes for orchestration.

The dimensions are large, with a hierarchical structure, and require reduction in redundancy and storage space.

Açıklama:

Veri ambarlamada Star şeması ve Snowflake şeması iki yaygın modeldir.

• Star Şeması: Merkezi bir fact tablosu ve bu tabloya doğrudan bağlı denormalize (ilişkisiz) boyut tablolarından oluşur. Daha basit bir yapıya sahiptir ve sorgu performansları genellikle daha iyidir çünkü daha az join gerektirir. Ancak boyut tablolarında tekrarlı veri (redundancy) daha fazladır.

• Snowflake Şeması: Yine merkezi bir fact tablosu ve bu tabloya bağlı boyut tablolarından oluşur, ancak boyut tabloları kendileri normalize edilmiş (ilişkili) olabilir. Yani bir boyut tablosu, başka boyut tablolarına bağlı olabilir, bu da hiyerarşik bir yapı oluşturur. Bu yapı, veri tekrarını azaltır ve disk alanından tasarruf sağlar. Ancak sorgular daha fazla join gerektirdiği için performans Star şemasına göre genellikle daha yavaş olabilir.

Şimdi seçeneklere bakalım:

1. The dimensions in the data warehouse are only one or two levels deep, and the users require complex analytical queries with joins across many dimensions. (Boyutlar sadece bir veya iki seviye derinliğinde ve kullanıcılar birçok boyut arasında join gerektiren karmaşık analitik sorgular istiyor.) – Boyutların sığ olması Star şemasına daha uygundur. Snowflake’in normalize yapısının (derin boyut hiyerarşisi) avantajını göstermez.

2. The individual data grains are voluminous, and the dimensions have many-to-many relationships with each other. (Bireysel veri “grain”leri hacimlidir ve boyutlar birbirleriyle çoktan çoğa ilişkilere sahiptir.) – Veri hacmi veya boyutlar arasındaki çoktan çoğa ilişkiler (ki bu genellikle bir köprü tablosu ile çözülür) doğrudan Star veya Snowflake şeması seçimini belirlemez.

3. The nature of the data is dynamic with frequent changes, and the inflow of data is continuous and rapid. (Verinin yapısı sık değişikliklerle dinamiktir ve veri akışı sürekli ve hızlıdır.) – Bu daha çok ETL/ELT süreci ve veri modelleme stratejisiyle (örn. SCD tipleri) ilgilidir, Star veya Snowflake şeması seçiminin temel belirleyicisi değildir.

4. The dimensions are large, with a hierarchical structure, and require reduction in redundancy and storage space. (Boyutlar büyüktür, hiyerarşik bir yapıya sahiptir ve veri tekrarının ve depolama alanının azaltılmasını gerektirir.) – Bu ifade tam olarak Snowflake şemasının kullanıldığı senaryoyu tanımlar. Büyük boyutlar ve hiyerarşik yapı, normalizasyonun (Snowflake) avantajlarını (redundancy’yi azaltma, depolama alanından tasarruf) ön plana çıkarır.

5. The users query the data in real-time and the response time needs to be very fast. (Kullanıcılar veriyi gerçek zamanlı sorguluyor ve yanıt süresinin çok hızlı olması gerekiyor.) – Hızlı yanıt süresi genellikle daha az join gerektiren Star şemasını veya özel indeksleme/agregasyon tekniklerini tercih etmeyi düşündürür, Snowflake’i değil.