1. GİRİŞ: MİKROSERVİS DEVRİMİNİN ÖNCÜSÜ VE MİMARI

2026 yılındayız ve "mikroservis" kavramı bugün yazılım dünyasının temel taşıysa, bunun en büyük müsebbiplerinden biri hiç kuşkusuz Amazon'dur. Amazon, henüz bulut bilişim kavramının bile emekleme aşamasında olduğu 2000'lerin başında, devasa monolitik sistemlerin (ünlü **Obidos**) hantallığı altında ezilirken bir karar verdi: "Hizmet Odaklı Mimari" (SOA) felsefesini uç noktaya taşıyarak her bir iş fonksiyonunu bağımsız, küçük ve otonom parçalara ayırmak. Bu karar, bugün dünyanın en büyük bulut sağlayıcısı olan AWS'nin (Amazon Web Services) de doğumuna zemin hazırlayan teknolojik bir patlamaydı.

Peki, Amazon'un tasarımı neden bugün hala tüm mühendisler için bir "kutsal kase" niteliğinde? Çünkü Amazon, sadece kodun değil, organizasyonun da mikroservislere uyması gerektiğini felsefi bir düzeyde kanıtladı. Ünlü "Two-Pizza Teams" (İki Pizzalı Takımlar) kuralından, hata payını minimize eden "Cell-based Architecture" (Hücresel Mimari) yapısına kadar Amazon, ölçeğin (scale) getirdiği karmaşıklığı nasıl yönetileceğinin blueprintini çıkardı. 2026'da Amazon mikroservis mimarisi; sadece sunucuların birbirine bağlanması değil, Event-Driven (Olay Güdümlü) sistemlerin, AI destekli otonom ölçeklemenin ve sunucusuz (serverless-first) bir geleceğin vücut bulmuş halidir.

Kimler İçin Önemli?

Bu teknik rehber; dağıtık sistemler inşa eden Sistem Mimarları, organizasyonel verimliliği mikroservislerle artırmak isteyen Mühendislik Yöneticileri ve AWS ekosisteminin derinliklerindeki "Amazon felsefesini" merak eden DevOps/Platform Mühendisleri için hazırlanmıştır.

Hangi Problemleri Çözüyor?

• Bağımlılık (Coupling) Krizi: Monolitik yapılardaki "bir yerdeki değişiklik her yeri bozar" korkusunu, katı API sözleşmeleriyle ortadan kaldırır.
• İnovasyon Hızı: Binlerce bağımsız takımın, birbirini beklemeden günde binlerce kez "deploy" yapabilmesini sağlar.
• Hata Yayılımı (Blast Radius): Bir sistemdeki çöküşün, tüm siteyi (örneğin amazon.com ana sayfasını) çökertmesini engeller.
• Operasyonel Yük: "You Build It, You Run It" (İnşa eden işletir) felsefesiyle sorumluluk ve kaliteyi en alt birime indirger.

2. KAVRAMSAL TEMELLER: AMAZON'UN GENETİK KODU

Amazon mikroservis dünyasını anlamak için sistemin teknik bileşenlerinden önce, bu sistemi doğuran felsefeyi kavramak gerekir.

2.1 Distributed Computing Manifesto (Dağıtık Hesaplama Manifestosu)

2000'lerin başında Amazon mühendisleri tarafından yayınlanan bu iç yazışma, veritabanına doğrudan erişimin yasaklanmasını ve her servisin verisine sadece kendi API'ı üzerinden erişilmesini emrediyordu. Bu, modern mikroservislerin temel anayasasıdır.

2.2 Two-Pizza Teams (İki Pizzalı Takımlar)

Jeff Bezos'un ünlü kuralı: "Bir takım, iki büyük pizzayla doyurulabiliyorsa ideal büyüklüktedir." (Genellikle 6-10 kişi). Bu ekipler, sahip oldukları servisin tasarımından, kodundan, testinden ve üretim ortamındaki performansından %100 sorumludur (Single-threaded Ownership).

2.3 Cell-based Architecture (Hücre Bazlı Mimari)

Sistemi devasa bir bütün yerine, birbirinin kopyası olan bağımsız "hücrelere" (cells) bölme yaklaşımıdır. Bir hücre çöktüğünde sadece o hücredeki kullanıcılar etkilenir (Limited Blast Radius), sistemin geri kalanı sarsılmaz.

2.4 Terminoloji

• Tiered Services: Servislerin kritiklik seviyesine göre (Core vs Additional) katmanlandırılması.
• Eventual Consistency: Dağıtık veri depolarında verinin anlık değil, kısa bir süre sonra tüm sistemde aynı hale gelmesi prensibi.
• API-First: Bir servisin geliştirilmesine, önce dış dünyaya vereceği "söz" olan API dokümantasyonuyla başlanması.

3. NASIL ÇALIŞIR? TEKNİK MİMARİ VE VERİ AKIŞI

Amazon mikroservisleri, 2026 yılında tamamen otonom ve olay odaklı (event-driven) bir sinir sistemi gibi çalışır.

3.1 Sistem Mimarisi: "Decentralized Everything"

1. API Gateway Katmanı: Tüm dış trafik (Web, Mobil, IoT) merkezi bir kapıdan (Amazon API Gateway) girer. Burada kimlik doğrulama ve yüksek hız sınırlaması yapılır.
2. Service Discovery (Hizmet Keşfi): Binlerce servis birbiriyle doğrudan IP üzerinden değil, **AWS Cloud Map** gibi dinamik servis kayıt sistemleri üzerinden konuşur.
3. Data Ownership: Her servisin kendi veritabanı (Private Database) vardır. Sipariş servisi **DynamoDB** kullanırken, Ürün Kataloğu **Elasticsearch** veya **Aurora** kullanabilir. Servisler birbirinin veritabanına asla "SQL sorgusu" atamaz.
4. Event Bus (Amazon EventBridge): Servisler arası iletişim büyük oranda asenkrondur. Bir işlem gerçekleştiğinde (Örn: Sipariş verildi), bu olay bir "event" olarak veri yoluna bırakılır ve ilgi duyan diğer servisler (Örn: Lojistik, E-posta) bu olayı yakalar.

3.2 Veri Akışı: Bir Siparişin Yolculuğu

Kullanıcı "Satın Al" butonuna bastığında: Gateway -> Order Service (DB'ye yaz) -> EventBridge (SiparişOluştu Eventi) -> Lojistik Servisi (Paketleme Başlat) & Ödeme Servisi (Karttan çekim) & Sadakat Servisi (Puan ekle). Bu süreçte hiç bir servis diğerinin yanıt vermesini beklemez (Non-blocking).

3.3 AI Destekli Otonom Ölçekleme (AIOps 2026)

2026'da Amazon mikroservisleri, trafik artışını beklemek yerine tahmin eder. AI modelleri, geçmiş alışveriş trendlerini ve küresel olayları analiz ederek, "Black Friday" başlamadan 30 dakika önce ilgili servislerin kapasitesini (containers/lambdas) otomatik olarak artırır.

4. GERÇEK DÜNYA KULLANIMLARI: AMAZON VE ÖTESİ

Mikroservis denilince akla gelen devler bu mimariyi nasıl uyguluyor?

4.1 Amazon Retail: Milyarlarca SKU Yönetimi

Amazon.com ana sayfası, tek bir sayfadan değil, arka planda yüzlerce farklı servisin (Öneri motoru, sepet, fiyatlandırma, reklamlar) API yanıtlarının birleşmesinden (Client-side aggregation) oluşur. Bir öneri servisi yavaşlasa bile sayfa açılır, sadece "Sizin için öneriler" kısmı boş kalır (Graceful Degradation).

4.2 Prime Video: Mevsimlik Monolitik Geri Dönüşü

İlginç bir vaka çalışması olarak; Prime Video ekibi, bazı video analiz iş yüklerinin mikroservislerle çok pahalıya mal olduğunu fark ederek (step functions ve lambda maliyetleri), belirli bir modülü 2023-2025 döneminde tekrar monolitike yakın bir yapıya çevirdi ve maliyeti %90 düşürdü. Bu, Amazon'un "dogmatik" değil "pragmatik" olduğunu kanıtlar.

4.3 Yemeksepeti (Türkiye): Bulut ve Ölçek

Türkiye'nin en büyük gıda operasyonlarından olan Yemeksepeti, AWS servislerini (Lambda, API Gateway) kullanarak tamamen sunucusuz (serverless) bir mikroservis mimarisine geçmiştir. Bu sayede trafik artışlarında altyapı yönetmekle uğraşmak yerine sadece koda odaklanabilmektedirler.

4.4 Netflix: Amazon'un En Büyük Müşterisi

Netflix, tüm mimarisini AWS mikroservisleri üzerine kurmuştur. Amazon'un teknik pratiklerini alıp Chaos Engineering gibi disiplinlerle zenginleştirerek karşılıklı bir inovasyon döngüsü yaratmışlardır.

4.5 Stripe: API-First Finans Mimari

Stripe, Amazon'un "API sözleşmesi sarsılmaz olmalıdır" kuralını en iyi uygulayan fintech devidir. Arka planda binlerce mikroservis dönerken, dış dünyaya tek ve kusursuz bir API deneyimi sunarlar.

5. AVANTAJLAR VE SINIRLAMALAR: GERÇEKÇİ BİR ANALİZ

Avantajlar

• Sınırsız Ölçeklenebilirlik: Sistemin geri kalanına dokunmadan sadece yoğun olan servisi (Örn: Ödeme) binlerce kat büyütebilirsiniz.
• Teknoloji Bağımsızlığı (Polyglot): Search servisi Go diliyle, AI servisi Python ile, Ödeme servisi Java/Rust ile yazılabilir.
• Hızlı Hata Tespiti: Her servis kendi loglarını ve metriklerini üretir, bir sorun olduğunda tam olarak hangi hücrenin (cell) patladığı anında görülür.
• Organizasyonel Uyum: Ekiplerin otonomisi, karar verme süreçlerini hızlandırır ve şirket içi bürokrasiyi azaltır.

Sınırlamalar / Zorluklar

• Network Latency (Ağ Gecikmesi): Çok fazla servis çağrısı, milisaniyelerin birikmesine ve toplam yanıtta yavaşlığa yol açabilir.
• Dağıtık Veri Karmaşası (Data Consistency): İki farklı servisteki verinin senkronizasyonu (Saga Pattern vb.) yönetilmesi zor bir operasyondur.
• Maliyet: Çok fazla küçük parça, daha fazla "inter-service" trafik ve daha fazla yönetim aracı (monitoring, tracing) maliyeti demektir.
• Gözlemlenebilirlik (Observability): Bir isteğin 50 servis gezdiği bir yapıda hatanın nerede olduğunu bulmak uzmanlık gerektirir.

6. ALTERNATİFLER VE KARŞILAŞTIRMA

Mimari yaklaşımların karşılaştırmalı tablosu:

7. EN İYİ PRATİKLER: AMAZON SRE TAVSİYELERİ

Amazon ölçeğinde bir sistem inşa etmek için uygulanması gereken altın kurallar:

7.1 Production Kullanımı ve Strateji

• You Build It, You Run It: Geliştiricilerin kodun "işletiminden" de sorumlu tutulması, kod kalitesini dramatik şekilde artırır.
• Formal API Contracts: API'nızda "breaking change" (geriye dönük uyumsuz değişiklik) yapmaktan kaçının. Versiyonlama (v1, v2) hayat kurtarır.
• Service Quotas & Throttling: Her servise bir kapasite limiti koyun. Bir servis diğerini istek bombardımanına tutarak çökertmesin.

7.2 Performans ve Ölçeklenebilirlik

• Cache-Aside Pattern: Mümkün olan her yerde veriyi önbelleğe alın ama ana veri kaynağını (Source of truth) her zaman güncel tutun.
• Database Sharding: Veritabanı büyüdüğünde dikeyde büyümek yerine yatayda parçalara (shards) bölün.

7.3 Güvenlik ve Dayanıklılık

• Chaos Testing: Sistemin zayıf noktalarını bulmak için üretim ortamında kontrollü kaos deneyleri yapın.
• IAM Roles: Her servis sadece ihtiyacı olan AWS kaynaklarına (Least Privilege) erişebilmelidir.

8. SIK YAPILAN HATALAR: MİKROSERVİS KABUSLARI

• Distributed Monolith (Dağıtık Monolit): Servisleri o kadar sıkı bağlamak (tightly coupled) ki, birini güncellemek için diğer 10'unu da güncellemek zorunda kalmak.
• Paylaşımlı Veritabanı: Birden fazla servisin aynı SQL tablosuna yazıp çizmesi. Bu, mikroservislerin tüm avantajını öldürür.
• Manual Deployment: Binlerce mikroservisi "sağ tıkla yayınla" yaparak yönetmeye çalışmak. CI/CD otomasyonu olmadan mikroservis yapılamaz.
• Over-engineering (Aşırı Mühendislik): 20 kullanıcılı bir startup için Amazon'un "Cell-based" mimarisini taklit etmeye çalışmak. Karmaşıklık altında boğulursunuz.
• Lack of Tracing: Bir hata olduğunda isteğin hangi servisler arasında kaybolduğunu göremiyorsanız, sistem tasarımınız eksiktir.

9. GELECEK TRENDLER: 2026 VE ÖTESİ

9.1 Serverless-Native Microservices

Amazon, "sunucu yönetme" devrini kapatıyor. 2026'da mikroservislerin %70'i artık EC2 sunucularında değil, AWS Lambda veya Fargate gibi tamamen "serverless" ortamlarda, sadece kullanıldığında ayağa kalkan fonksiyonlar olarak koşturulacak.

9.2 Self-Driving Architecture (Kendi Kendine Karar Veren Mimari)

AI ajanları devrede! Bir servis yavaşladığında, AI ajanları kodu analiz edecek, darboğazı bulacak ve geliştiriciye gitmeden geçici bir "patch" veya kapasite artışı uygulayabilecek.

9.3 Green Computing & Sustainability

Mikroservislerin işlemci gücü kullanımı, karbon ayak izine göre optimize edilecek. "Hangi servisi nerede koşturursak daha az enerji harcarız?" sorusu, mimari kararların bir parçası olacak.

EK BÖLÜMLER

Sık Sorulan Sorular (FAQ)

1. Neden her şeyi mikroservis yapmıyoruz?

   Çünkü mikroservisler ciddi bir operasyonel karmaşıklık getirir. Eğer monolitik bir yapı ihtiyacınızı karşılıyorsa, boş yere bu karmaşıklığa girmemelisiniz (Service complexity tax).

2. İki Pizzalı Takımlar kuralı hala geçerli mi?

   Evet, Amazon'un çevikliğinin sırrı hala bu küçük ve otonom takımlarda yatıyor.

3. AWS ve Amazon Mikroservisleri aynı şey mi?

   Amazon Web Services (AWS), Amazon'un kendi mikroservislerini koşturmak için geliştirdiği araçların dünyaya sunulmuş halidir. Amazon, kendi altyapısının en büyük müşterisidir.

4. Eventual Consistency bir sorun mu?

   Bir "banka havalesi" için sorun olabilir ama bir "ürün yorumu" veya "sepete ekleme" için kabul edilebilir bir durumdur. Doğru yerde doğru modeli seçmek gerekir.

5. Mikroservislere ne zaman geçilmeli?

   Kod tabanınız tek bir ekibin yönetemeyeceği kadar büyüdüğünde ve deployment süreleri haftaları bulmaya başladığında geçiş vaktidir.

6. Amazon her şeyi Lambda mı yaptı?

   Hayır, kritik ve sürekli yük alan servisler hala kotalı konteynerlarda (EKS/ECS) koşuyor; ancak olay odaklı ve değişken iş yüklerinde Lambda (Serverless) tercih ediliyor.

7. Saga Pattern nedir?

   Birden fazla mikroservisi içine alan bir işlemin (transaction), bir servis hata verdiğinde önceki adımların "geri alınması" (compensation) sürecini yöneten desendir.

8. Cell-based architecture maliyeti artırır mı?

   Donanım maliyeti olarak evet, ancak felaket anındaki itibar ve para kaybını önlediği için büyük ölçekte çok daha Karlıdır.

Anahtar Kavramlar Sözlüğü

Blast Radius (Patlama Yarıçapı)

Bir sistem hatasının, tüm platformun ne kadarını etkileyebileceği ölçeği.

Single-Threaded Ownership

Bir takımın, başka hiçbir işle meşgul olmadan sadece tek bir işe/servise odaklanması prensibi.

Graceful Degradation

Sistemin bir parçası çöktüğünde tüm sitesinin kapanması yerine, sadece o parçanın işlevsiz kalması ama geri kalanın çalışmaya devam etmesi.

Decoupling

Servisler arasındaki bağımlılıkların minimuma indirilmesi süreci.

Polyglot Persistence

Her mikroservisin kendi ihtiyacına en uygun veritabanı tipini (SQL, NoSQL, Graph) kullanması.

Öğrenme Yol Haritası (Amazon Architecture Specialist 2026)

1. Aşama 1: AWS Temelleri. EC2, S3 ve IAM gibi temel servislerin çalışma mantığını kavrayın.
2. Aşama 2: NoSQL ve DynamoDB. Mikroservislerin kalbi olan dağıtık veritabanlarını ve şema tasarımını öğrenin.
3. Aşama 3: Konteyner Dünyası. Docker, ECS ve EKS (Kubernetes) ile servisleri nasıl paketleyeceğinizi ve orkestre edeceğinizi keşfedin.
4. Aşama 4: Serverless Mastery. AWS Lambda ve API Gateway ile kod yazmadan altyapı yönetmeyi pratiğe dökün.
5. Aşama 5: Event-Driven Systems. SQS, SNS ve özellikle EventBridge kullanarak asenkron mimariler kurun.
6. Aşama 6: CI/CD Otomasyonu. AWS CodePipeline ve Terraform/CDK ile "Infrastructure as Code" (IaC) prensiplerini uygulayın.
7. Aşama 7: Gözlemlenebilirlik. CloudWatch, X-Ray ve dağıtık tracing araçlarıyla sistemin röntgenini çekmeyi öğrenin.
8. Aşama 8: Mimari Karar Verme. Ne zaman mikroservis, ne zaman monolit seçileceğine dair stratejik analiz yeteneği geliştirin.