Polyglot Mimari: Java + .NET + Python Aynı Platformda Nasıl Yaşar?

"Tek bir dil seçin, tüm servisleri onunla yazın" öğüdü çok duyulan bir şey. Mantıklı duyuluyor: ekip tek bir dili bilir, araçlar tek tek olur, debugging hep aynı şekilde yapılır. Gerçek dünyada bu her zaman mümkün değil — hatta çoğu zaman mümkün olmamalı.

Bizim platformumuzda üretimde Java, .NET Core, PHP, Python ve Node.js aynı anda çalışıyor. Bu bir "tarihsel kaza" değil, bilinçli bir karardı. Bu yazıda polyglot mimarinin ne zaman mantıklı olduğunu, ne zaman pişmanlık getirdiğini anlatacağım.

Neden birden fazla dil?

İlk sebep: farklı dillerin farklı ekosistemleri var. Her dilin güçlü olduğu bir alan var, o alanda alternatif bir dile zorlamak kaynak israfı.

Bizim sistemdeki örnekler:

• Java (Spring) — olgun game server framework'lerimiz, bol domain kodu, güçlü tipleme. Core oyun mantığı için ideal.
• .NET Core — bazı oyun server varyantları ve API servisleri. Özellikle bazı üçüncü parti entegrasyonlar .NET'te daha rahat.
• Python — asenkron consumer servisler, veri işleme, ML entegrasyonları. Ekosistem bu alanlarda net önde.
• Node.js — WebSocket tabanlı real-time facade'ler. Event-loop model'i bu tür iş yükleri için uygun.

Bu dört dili bir arada tutmak zor mu? Kesinlikle. Ama gerçekten ihtiyaç duydukça kullanıldığı için değerli.

İkinci sebep: ekip kararı

Java bilen bir developer ekibe katılırken "artık .NET yaz" demek verimsiz. Aynı şekilde Python data ekibini Java'ya geçirmek, onlardan veri bilimi birikiminin yarısını çöpe atmalarını istemek demek.

Polyglot mimari, ekibi oldukları gibi ölçeklendirmenize izin veriyor. "Java uzmanı mı gerek, Python mu gerek?" sorusunu teknik mantığa göre karar verebiliyorsun — "ekibin tamamı Java bilmek zorunda" kısıtı altında değil.

Hangi yerler polyglot'un değerli olduğu yerler

1. Dil-özel kütüphane ihtiyacı

• ML için Python (PyTorch, scikit-learn)
• Özel oyun framework'leri Java'da
• Windows/Microsoft entegrasyonu için .NET

2. Performans profili

• CPU-heavy işler Rust/Go daha iyi
• I/O-heavy işler Node.js/Python daha uygun
• JVM işleri Java daha olgun

3. Uzmanlık

• Ekip zaten bir dilde güçlüyse, o dili taşımak ekibi tepeyi aşağı itmek demek

Ama bu kadar esnek olmanın bir bedeli var

Polyglot mimari "bedava" değil. En azından üç boyutta fiyatını ödersiniz:

1. Operasyonel karmaşa

Her dilin kendi:

• Paket yöneticisi (Maven/NuGet/pip/npm)
• Runtime karakteristiği (JVM warm-up, Python GIL, Node event loop)
• Performans tuning aracı
• Deployment kuralları (Dockerfile, Helm chart)

Bu, "tek dil" ekipten daha fazla yatırım gerektiriyor. Küçük bir ekiple polyglot yapmak pek tavsiye edilmiyor.

2. Gözlemlenebilirlik

Tracing, logging, metric toplama her dilde farklı şekilde yapılır. OpenTelemetry bu sorunu azaltsa da kaldırmıyor. Sentry entegrasyonu farklı, log formatı farklı, exception stack trace farklı.

Çözüm: platform ekibi olarak tüm dillerde tutarlı minimum standartlar koyuyorsunuz. Örnek:

• Her log JSON formatında
• Her log minimum şu 5 field'ı içerir
• Her servis /health ve /metrics endpoint'lerini aynı şemada sunar

Bu tür standartlar olmadan polyglot'ta gözlemlenebilirlik dağılır.

3. Yeniden kullanılabilir kod

Java ekibin yazdığı bir modülü Python ekibi kullanamaz. Bu, aynı mantığı iki dilde yazmak anlamına gelebilir. Çözüm: shared primitive'ler servisler olarak. Örn. auth kontrolü bir servis, hem Java hem Python çağırır.

Kütüphane paylaşımı değil, servis paylaşımı. Dilden bağımsız.

Ne zaman polyglot YAPMAMAK gerekir

Bir kurala çok dikkat ediyorum: küçük bir ekipte polyglot yapma. 5-kişilik bir ekip 4 dili iyi yönetemez. Bu ekipteki her developer haftada 4 dilde bug chasing yapmak zorunda kalır. Tükenme garantili.

Polyglot mantıklı: 15+ developer, en az 2-3 ekip, platform ekibi var, her dilin "owner"ı var. Bizim durumumuzda aynen böyle.

Polyglot yıkıcı: 3 developer, hepsi her şey yapıyor, ama birinin yazdığı servisi diğeri açınca farklı bir dilin rituellerine maruz kalıyor.

Standardizasyon: nereye, nereye değil

Bizde şu kurallar var:

Standartlaştırılmış:

• Container build (Dockerfile pattern'i)
• Deployment (Helm chart şablonu)
• Log format (JSON + common fields)
• Health endpoint şeması
• CI/CD pipeline
• Secret yönetimi (vault)

Standartlaştırılmamış:

• Dil seçimi (ekip karar veriyor)
• Framework içi mimari (her ekip kendi yapısı)
• Test stratejisi (çerçeveler farklı, ama %80 coverage zorunlu)

Bu dengeyi bulmak zaman aldı. Başlarda ya fazla kurallar koyduk (ekipler kızdı), ya hiç kural koymadık (kaos oldu). Şu anki set kararlı çalışıyor.

Sonuç

Polyglot mimari bir özgürlük değil, bir sorumluluk. İyi yönetilince ekibin üretkenliğini katlar; kötü yönetilince ekibi yavaşlatır. Karar kriteri basit: "Bu dili neden kullanıyoruz?" sorusuna net cevap var mı? Yoksa, rahatsızlık için gereksiz bir tercih yapmışsınızdır.

Tek dil nicedir; polyglot yerindedir. İkisi de yerli yerinde güzel.