Teknoloji dünyasında herkesin gizliden gizliye Netflix, Spotify veya Uber olmak istediği bir sır değil. Konferanslarda, YouTube videolarında ve Medium makalelerinde bu teknoloji devlerinin kendi devasa sorunlarını nasıl "Mikroservis (Microservices)" mimarisiyle çözdüklerini dinliyoruz. Sonra ne mi oluyor? Daha ürün/pazar uyumunu (Product-Market Fit) bile bulamamış, toplamda 3 tane yazılımcısı olan küçük bir startup, basit bir e-ticaret uygulamasını 15 farklı mikroservise bölerek kodlamaya başlıyor.

Sonuç: Tam bir mühendislik kâbusu ve harcanan milyonlarca lira.

Eskiden "Monolit" (Monolith) dediğimiz tek parça uygulamalar yazardık. Kullanıcı kaydı, ödeme sistemi, ürün listeleme... Hepsi tek bir kod deposunda (repo), tek bir veritabanına bağlı olarak çalışırdı. Kodun içinde bir hata (bug) olduğunda, nerede patladığını bulmak saniyeler sürerdi.

Ancak "Mikroservis" modasıyla birlikte, bu basit sistemi parçalara ayırmaya başladık. Ödeme sistemi ayrı bir uygulama oldu, kullanıcı servisi ayrı, bildirim servisi ayrı. Teoride kulağa harika geliyor: "Ödeme servisi çökerse, sitenin kalanı çalışmaya devam eder!"

Pratikte ise şu olur: Kullanıcı bir ürün satın alır. Sipariş servisi, ödeme servisine ağ üzerinden (network) bir istek atar. O sırada ağda anlık bir yavaşlama (latency) olur, istek zaman aşımına uğrar (timeout). Sipariş servisi "Ödeme alınamadı" der ama aslında ödeme servisi o isteği yarım saniye sonra alıp müşterinin kartından parayı çekmiştir. Müşteri parasını kaybeder ama sipariş oluşmaz (Eventual Consistency problemleri).

Artık sadece kod yazmıyorsunuz; ağ gecikmelerini (Network Latency), dağıtık sistemlerde veri tutarlılığını (Distributed Transactions), servisler arası güvenliği (mTLS), birbirleriyle nasıl haberleşeceklerini (Message Brokers, gRPC) çözmeye çalışıyorsunuz. Eskiden basit bir fonksiyon çağırmak (Function Call) 1 milisaniye sürerken, şimdi o işlemi yapmak için veriyi JSON'a çevirip internet üzerinden başka bir sunucuya göndermek zorundasınız.

Mikroservisler, teknik bir sorunu çözmez; teknik sorunu "Organizasyonel" bir soruna çevirir. Eğer şirketinizde yüzlerce yazılımcınız varsa, herkesin aynı kod deposunda çalışması imkansızlaştığı için mikroservislere geçersiniz. Netflix bunu yapmak zorundaydı. Ama sizin şirketiniz Netflix değil.

Eğer yeni bir projeye başlıyorsanız veya küçük/orta ölçekli bir ekipseniz, yapacağınız en zekice hamle mükemmel bir "Modüler Monolit" (Modular Monolith) yazmaktır. Tek repo, tek veritabanı, tek CI/CD pipeline'ı. Dağıtımı (deploy) kolay, izlemesi (monitoring) kolay, hatasını bulması (debugging) kolaydır. Milyonlarca kullanıcıya kadar da bir monolit ile mükemmel bir şekilde ölçeklenebilirsiniz (GitHub, Shopify ve StackOverflow uzun yıllar monolit olarak çalıştı ve devasa boyutlara ulaştılar).

Gereksiz mimari karmaşıklık, girişimlerin sessiz katilidir. Havalı mimariler uğruna basitliği feda etmeyin. Bırakın monolitler monolit olarak kalsın, inanın bana gece çok daha rahat uyuyacaksınız.