Pazaryerinde Mikro Hizmet Mimarisi: 2026'da Ölçeklenebilir ve Bakım Kolay Platform Altyapısı Kurma Rehberi

Pazaryeri platformları büyüdükçe karşılaşılan en kritik sorunlardan biri altyapı ölçeklenebilirliğidir. Monolitik bir yapıyla başlayan birçok platform, kullanıcı sayısı ve işlem hacmi arttıkça performans dar boğazlarıyla karşılaşır. Bir satıcı panelindeki yavaşlık, tüm sistemi etkiler. Ödeme entegrasyonundaki bir hata, sipariş yönetimini kilitleyebilir. İşte bu noktada mikro hizmet mimarisi devreye girer.

Bu rehberde, pazaryeri platformunuz için mikro hizmet mimarisini nasıl tasarlayacağınızı, hangi servislerin ayrılaştırılması gerektiğini ve 2026'da hangi teknolojilerin öne çıktığını inceleyeceğiz. Özellikle orta ve büyük ölçekli pazaryerleri için bu mimari yaklaşım, uzun vadede bakım maliyetlerini düşürürken büyümeyi destekleyen bir altyapı sunar.

Monolitik Yapıdan Mikro Hizmetlere Geçiş Neden Önemli?

Pazaryeri platformları doğaları gereği karmaşık sistemlerdir. Satıcı yönetimi, ürün katalogları, sipariş işleme, ödeme entegrasyonu, kargo hesaplama, kullanıcı yetkilendirme, bildirim sistemleri ve analitik gibi onlarca farklı işlev tek bir çatı altında toplanır. İlk aşamada monolitik bir yapı bu işlevleri yönetebilir görünse de, platform büyüdükçe ciddi sorunlar ortaya çıkar.

Monolitik yapıda bir modüldeki değişiklik, tüm sistemin yeniden deploy edilmesini gerektirir. Bir satıcı raporlama özelliğinde yapılacak güncelleme için tüm platformun yeniden başlatılması, kesinti süresi ve risk anlamına gelir. Ayrıca farklı modüllerin farklı ölçeklendirme ihtiyaçları vardır. Örneğin, Black Friday döneminde ürün arama servisi yoğun trafik alırken, kullanıcı ayarları servisi nispeten sakin kalabilir. Monolitik yapıda tüm sistemi ölçeklendirmek zorunda kalırsınız, bu da maliyet artışı demektir.

Mikro hizmet mimarisinde her işlev bağımsız bir servis olarak çalışır. Kendi veritabanı, kendi deployment döngüsü ve kendi ölçeklendirme politikası vardır. Bir serviste yaşanan sorun diğerlerini etkilemez. Ödeme servisinde bir gecikme olsa bile ürün arama ve sepet işlemleri kesintisiz devam eder.

Pazaryeri İçin Temel Mikro Hizmet Tasarımı

Bir pazaryeri platformunu mikro hizmetlere ayırırken iş alanlarına (domain) göre gruplandırma yapmak en yaygın yaklaşımdır. Domain-Driven Design (DDD) prensipleriyle tasarlanmış bir mimaride, her servis kendi iş alanının sorumluluğunu üstlenir.

Kimlik ve Erişim Yönetimi Servisi

Kullanıcı kayıt, giriş, çok faktörlü doğrulama, rol tabanlı yetkilendirme (RBAC) ve oturum yönetimi bu servisin sorumluluğundadır. Pazaryerlerinde üç farklı kullanıcı tipi bulunur: platform yöneticileri, satıcılar ve alıcılar. Her birinin erişim hakları ve izinleri farklıdır. Kimlik servisi, OAuth 2.0 ve OpenID Connect protokollerini kullanarak güvenli bir kimlik doğrulama altyapısı sunar.

Ürün Katalog Servisi

Ürün listeleme, kategori yönetimi, ürün özellikleri, varyantlar, stok durumu ve fiyat bilgileri bu serviste yönetilir. Katalog servisi, yüksek okuma trafiğine sahip olduğu için okuma optimizasyonlu bir veritabanı yapısı gerektirir. Elasticsearch gibi arama motorları entegre edilerek hızlı ürün arama ve filtreleme sağlanır. Ürün görselleri için CDN entegrasyonu bu servisin sorumluluğundadır.

Sipariş ve Ödeme Servisi

Sepet yönetimi, sipariş oluşturma, ödeme işlemleri, komisyon hesaplama ve iade süreçleri bu servisin kapsamındadır. PCI DSS uyumluluğu gerektiren ödeme işlemleri için ayrı bir ödeme geçidi entegrasyonu yapılabilir. Sipariş durumu yönetimi (Sipariş Verildi, Ödeme Bekleniyor, Kargoya Verildi, Teslim Edildi) bir durum makinesi (state machine) ile yönetilir.

Satıcı Yönetim Servisi

Satıcı kaydı, onay süreci, performans takibi, komisyon oranları, ödeme planları ve satıcı paneli işlevleri bu serviste bulunur. Her satıcının kendi mağaza ayarları, kargo politikaları ve iade kuralları olabilir. Satıcı performans metrikleri (sipariş karşılama süresi, iade oranı, müşteri puanı) bu servis tarafından hesaplanır. Pazaryerinde satıcı performansını doğru KPI'larla ölçmek hakkında detaylı bilgi için ilgili rehberimizi inceleyebilirsiniz.

Bildirim Servisi

E-posta, SMS, push notification ve uygulama içi bildirimler tek bir servis üzerinden yönetilir. Bildirim tercihleri, şablon yönetimi ve gönderim zamanlaması bu servisin sorumluluğundadır. Olay tabanlı bir mimari kullanılarak, sipariş durumu değiştiğinde ilgili tüm taraflara otomatik bildirim gönderilir.

Arama ve Keşif Servisi

Pazaryerlerinde kullanıcı deneyiminin en kritik bileşeni, aradığı ürünü hızlı bulmaktır. Arama servisi, Elasticsearch veya Apache Solr üzerinde çalışır. Fuzzy matching, autocomplete, faceted search ve semantik arama gibi özellikler bu serviste sağlanır. Yapay zeka destekli ürün önerileri de bu servisin bir parçası olarak çalışabilir.

Kargo ve Lojistik Servisi

Kargo firması entegrasyonları, kargo ücreti hesaplama, kargo takip numaraları ve teslimat durumu güncellemeleri bu serviste yönetilir. Farklı kargo firmalarının API'leri bu servis üzerinden standartlaştırılarak diğer servislere sunulur.

İletişim Desenleri: Senkron mu Asenkron mu?

Mikro hizmetlerin birbiriyle iletişim kurması için iki temel yaklaşım vardır. Senkron iletişim için REST API veya gRPC kullanılırken, asenkron iletişim için mesaj kuyrukları (RabbitMQ, Apache Kafka) tercih edilir.

Pazaryeri platformlarında her iki yaklaşımın da kullanım alanları vardır. Ödeme onayı gibi kritik ve zaman duyarlı işlemler senkron çağrılarla yönetilir. Ancak sipariş durumu değişikliği, bildirim gönderimi veya analitik veri toplama gibi işlemler asenkron olarak işlenir. Asenkron iletişim, sistemlerin gevşek bağlı (loosely coupled) olmasını sağlar ve bir servisteki yavaşlama diğerlerini etkilemez.

Event-driven mimari, pazaryerleri için özellikle uygundur. Bir sipariş oluşturulduğunda "OrderCreated" olayı yayınlanır. Bu olayı dinleyen bildirim servisi alıcıya onay e-postası gönderir, stok servisi rezervasyon yapar, analitik servisi yeni sipariş verisini kaydeder. Her servis kendi hızında çalışır, hiçbiri diğerini beklemek zorunda kalmaz.

Veri Yönetimi Stratejileri

Mikro hizmet mimarisinde her servisin kendi veritabanı olması önerilir. Bu yaklaşım, servislerin bağımsızlığını korur ve veri modellerinin servis ihtiyaçlarına göre optimize edilmesini sağlar. Ancak bu durum, veri tutarlılığı ve sorgulama karmaşıklığı gibi yeni zorluklar doğurur.

Saga pattern, dağıtık işlemleri yönetmek için kullanılır. Bir sipariş oluşturulurken birden fazla serviste işlem yapılması gerekir: stok düşümü, ödeme provizyonu, sipariş kaydı. Eğer bu işlemlerden biri başarısız olursa, önceki işlemleri geri almak gerekir. Saga pattern, her adım için bir telafi işlemi (compensating transaction) tanımlayarak veri tutarlılığını sağlar.

CQRS (Command Query Responsibility Segregation) patterni, okuma ve yazma işlemlerini ayırır. Sipariş oluşturma gibi yazma işlemleri ilişkisel veritabanına yapılırken, sipariş sorgulama gibi okuma işlemleri için ayrı bir okuma modeli (read model) oluşturulur. Bu okuma modeli, Elasticsearch veya MongoDB gibi farklı bir veritabanında tutulabilir ve hızlı sorgulama sağlar.

2026'da Kullanılan Teknolojiler ve Araçlar

Mikro hizmet mimarisi için 2026'da öne çıkan teknolojiler şunlardır:

Konteyner Orkestrasyonu: Kubernetes, mikro hizmetlerin deploy edilmesi, ölçeklendirilmesi ve yönetilmesi için standart hale gelmiştir. Helm chart'lar ile servis tanımları yeniden kullanılabilir hale getirilir. Horizontal Pod Autoscaler (HPA) ile trafik artışlarına otomatik yanıt verilir.

API Gateway: Kong, Traefik veya AWS API Gateway gibi araçlar, tüm mikro servislere tek bir giriş noktası sağlar. Kimlik doğrulama, rate limiting, loglama ve yönlendirme gibi cross-cutting concerns bu katmanda yönetilir.

Servis Keşfi ve Yük Dengeleme: Consul, etcd veya Kubernetes'in kendi servis keşfi mekanizmaları, servislerin birbirini bulmasını sağlar. Dinamik yük dengeleme ile trafik sağlıklı instancelara yönlendirilir.

Mesaj Kuyrukları: Apache Kafka, yüksek throughput gerektiren olay akışları için tercih edilirken, RabbitMQ daha basit kuyruk senaryoları için uygundur. Cloud-native çözümler olarak AWS SQS/SNS, Google Pub/Sub veya Azure Service Bus kullanılabilir.

Dağıtık İzleme: OpenTelemetry standartları ile servisler arası çağrılar izlenir. Jaeger veya Zipkin ile distributed tracing yapılır. Prometheus ve Grafana ile metrikler toplanır ve görselleştirilir. Centralized logging için ELK Stack (Elasticsearch, Logstash, Kibana) veya Loki kullanılır.

Güvenlik ve Ağ Yalıtımı

Mikro hizmet mimarisinde güvenlik, servisler arası iletişimden dış dünyaya açılan API'lere kadar geniş bir yelpazeyi kapsar. Service mesh teknolojileri (Istio, Linkerd) servisler arası trafiği yönetir, mTLS ile servisler arası iletişim şifrelenir.

Her servisin minimum yetki prensibiyle çalışması önemlidir. Bir servisin ele geçirilmesi durumunda diğer servislere erişimi kısıtlanmalıdır. Network policy'ler ile hangi servisin hangi servisle iletişim kurabileceği tanımlanır.

API Gateway üzerinden yapılan rate limiting ve DDoS koruması, dış saldırılara karşı ilk savunma hattını oluşturur. JWT token'ları ile her istek kimlik doğrulamasından geçirilir ve yetkilendirme kontrolü yapılır. Pazaryeri platformlarında API güvenliği hakkında daha fazla bilgi için ilgili yazımıza göz atabilirsiniz.

Maliyet ve Performans Dengesi

Mikro hizmet mimarisi, doğru uygulandığında maliyet tasarrufu sağlar. Her servis kendi ihtiyaçlarına göre ölçeklendirilebilir. Yoğun trafik alan arama servisi için daha fazla kaynak ayrılırken, az kullanılan raporlama servisi için minimal kaynak yeterli olur. Ancak bu mimari, operasyonel karmaşıklık getirir. Daha fazla servis, daha fazla log, daha fazla izleme noktası anlamına gelir.

Küçük ve yeni başlayan pazaryerleri için monolitik yapıyla başlayıp, büyüme aşamasında kilit servisleri ayırmak daha pratik bir yaklaşım olabilir. Örneğin, önce arama ve ödeme servislerini ayırmak, ardından diğer servisleri kademeli olarak mikro hizmetlere dönüştürmek riski azaltır.

Ölçeklenebilirlik ve Gelecek Hazırlığı

Mikro hizmet mimarisi, pazaryeri platformunuzun gelecekteki büyümeye hazır olmasını sağlar. Yeni bir özellik eklenmesi gerektiğinde, mevcut servisleri etkilemeden yeni bir servis oluşturulabilir. Uluslararası genişleme planlandığında, çoklu para birimi ve dil desteği için ayrı servisler eklenebilir.

Serverless fonksiyonlar, belirli işlevler için mikro hizmetlerin ötesine geçer. Ürün görseli işleme, fatura oluşturma veya periyodik raporlama gibi işler için AWS Lambda, Google Cloud Functions veya Azure Functions kullanılabilir. Bu fonksiyonlar yalnızca çalıştıkları süre için ücretlendirilir, boşta beklediklerinde maliyet oluşmaz.

API Tasarımı ve Versiyonlama

Mikro hizmet mimarisinde API tasarımı kritik öneme sahiptir. Her servis, dış dünyaya açık API'ler ve diğer servislerle iletişim için iç API'ler sunar. RESTful API tasarım prensipleri takip edilirken, GraphQL de özellikle mobil uygulamalar için tercih edilebilir.

API versiyonlama stratejisi belirlemek zorunludur. URI tabanlı versiyonlama (api.pazaryeri.com/v1/urunler), header tabanlı versiyonlama veya consumer-driven versiyonlama yaklaşımları kullanılabilir. Versiyonlama politikası net bir şekilde dokümante edilmeli ve API kullanıcılarına (hem iç hem dış) önceden bildirilmelidir.

OpenAPI (Swagger) spesifikasyonları ile API dokümantasyonu otomatik olarak oluşturulur. Bu dokümantasyon, hem geliştirici ekiplerin entegrasyon süreçlerini hızlandırır hem de dış API kullanıcıları için self-service bir deneyim sunar. API Gateway üzerinden API dokümantasyon portalı yayınlanabilir.

Test Stratejileri ve Kalite Güvencesi

Mikro hizmet mimarisinde test stratejisi, monolitik yapılardan farklıdır. Her servis için unit testler, integration testler ve contract testler yazılır. Contract testing (Pact gibi araçlarla), servisler arası API sözleşmelerinin ihlal edilmediğini doğrular.

End-to-end testler, birden fazla servisi kapsayan iş akışlarını test eder. Bir sipariş oluşturma senaryosu, ürün servisi, stok servisi, ödeme servisi ve bildirim servisini birlikte test etmeyi gerektirir. Test ortamları, production ortamını mümkün olduğunca yansıtmalıdır.

Chaos engineering prensipleri uygulanarak sistemin dayanıklılığı test edilir. Rastgele servisler kapatılarak sistemin nasıl tepki verdiği gözlemlenir. Circuit breaker pattern'leri ile bir servisteki arızanın diğer servislere yayılması engellenir.

Sürekli Entegrasyon ve Dağıtım (CI/CD)

Mikro hizmet mimarisi, güçlü bir CI/CD altyapısı gerektirir. Her servis için ayrı bir CI/CD pipeline'ı oluşturulur. Kod değişikliği commit edildiğinde otomatik olarak build, test ve deploy süreçleri tetiklenir.

GitOps prensipleri uygulanarak, infrastructure-as-code (IaC) ile Kubernetes konfigürasyonları yönetilir. ArgoCD veya Flux gibi araçlar ile Git repository'sindeki değişiklikler otomatik olarak Kubernetes kümesine uygulanır. Blue-green deployment veya canary deployment stratejileri ile risk minimize edilir.

Feature flags ile özellikler kontrollü olarak yayınlanır. Yeni bir özellik önce iç kullanıcılara, ardından beta kullanıcılara, son olarak tüm kullanıcılara açılır. Bir sorun tespit edilirse feature flag kapatılarak özellik hızla devre dışı bırakılabilir.

Ek Organizasyonu ve Conway Yasası

Conway Yasası, sistemlerin organizasyonun iletişim yapısını yansıttığını söyler. Mikro hizmet mimarisinde her servis için ayrı bir ekip sorumludur. Bu yaklaşım, ekiplerin bağımsız çalışmasını, hızlı karar almasını ve kendi servislerinin tüm yaşam döngüsünden sorumlu olmasını sağlar.

Platform mühendisliği ekibi, ortak altyapı servislerini (API Gateway, message broker, monitoring) yönetir. Her product ekibi, kendi iş alanına ait servisleri geliştirir ve işletir. Bu yapı, büyük organizasyonlarda ölçeklenebilir bir çalışma modeli sunar.

Dokümantasyon kültürü kritik öneme sahiptir. Her servisin README dosyası, API dokümantasyonu, mimari karar kayıtları (ADR) ve operasyonel prosedürleri olmalıdır. Bu dokümantasyon, yeni ekip üyelerinin adaptasyonunu hızlandırır ve bilgi paylaşımını kolaylaştırır.

Platformunuz büyüdükçe mikro hizmet mimarisi size esneklik, ölçeklenebilirlik ve bakım kolaylığı sağlar. Doğru tasarım kararlarıyla, 2026 ve sonrasında pazaryeri platformunuzu rekabetçi bir altyapı üzerine inşa edebilirsiniz. Pazaryeri kurma maliyetleri hakkında daha fazla bilgi almak ve altyapı yatırımınızı planlamak için fiyatlandırma sayfamızı inceleyebilirsiniz.

Mikro hizmetlere geçiş, bir gecede yapılacak bir değişiklik değildir. Kademeli, planlı ve ölçülebilir bir süreçtir. Mevcut monolitik yapınızı analiz edin, en çok sorun yaşanan alanlardan başlayarak servisleri ayırın, her adımda izlenebilirlik ve test altyapısını kurun. Bu şekilde, pazaryeri platformunuz geleceğin gereksinimlerine hazır, ölçeklenebilir ve dayanıklı bir yapıya kavuşur.

S: Pazaryerim için mikro hizmet mimarisine ne zaman geçmeliyim?

C: Günlük işlem hacminiz 10.000'in üzerine çıktığında, monolitik yapıda deployment süreleri 30 dakikayı aştığında veya farklı modüllerin farklı ölçeklendirme ihtiyaçları doğduğunda geçiş zamanı gelmiş demektir. Ayrıca ekibiniz 15-20 geliştiriciyi aştığında, bağımsız ekiplerin farklı servisler üzerinde çalışması verimliliği artırır.

S: Mikro hizmet mimarisi maliyetleri artırır mı?

C: İlk aşamada altyapı ve operasyonel maliyetler artabilir. Ancak uzun vadede, her servisin ihtiyaca göre ölçeklendirilmesi sayesinde kaynak kullanımı optimize edilir. Black Friday gibi yoğun dönemlerde yalnızca arama ve ödeme servislerini ölçeklendirmek, tüm sistemi ölçeklendirmekten çok daha ekonomiktir. Ayrıca daha hızlı deployment döngüleri geliştirici verimliliğini artırır.

S: Küçük bir pazaryeri için mikro hizmet uygun mu?

C: Günlük sipariş sayısı 1.000'in altında olan bir platform için mikro hizmet mimarisi erken olabilir. Monolitik yapıyla başlayıp, büyüme aşamasında kilit servisleri (arama, ödeme) ayırmak daha pratiktir. Ancak mimariyi baştan mikro hizmetlere uygun tasarlamak, gelecekteki geçişi kolaylaştırır.

S: Mikroservisler arasında veri tutarlılığı nasıl sağlanır?

C: Saga pattern kullanarak dağıtık işlemleri yönetebilirsiniz. Her adımda bir telafi işlemi tanımlanır. Olay tabanlı mimari ile servisler arası veri senkronizasyonu sağlanır. CQRS patterni ile okuma ve yazma modelleri ayrılarak tutarlılık optimize edilir. Son okuma tutarlılığı (eventual consistency) çoğu pazaryeri senaryosu için yeterlidir.

S: Hangi programlama dillerini kullanmalıyım?

C: Mikroservislerde her servis farklı bir dilde yazılabilir. Yüksek performans gerektiren arama ve öneri servisleri için Go veya Rust, iş mantığı yoğun servisler için Java veya Python, hızlı prototipleme gereken servisler için Node.js tercih edilebilir. Ancak ekiibinizin yetkinliklerine göre standartlaşmak, bakım kolaylığı sağlar.