MicroShop
İki farklı şekilde geliştirilip yük altında ölçülen tek bir e-ticaret uygulaması — bir backend’i servislere böldüğünüzde gerçekte neyin değiştiğini inceleyen bir bitirme tezi.
- Rol
- Tek başına — bitirme tezi projesi
- Yıl
- 2026
- Teknolojiler
- React, TypeScript, Express, PostgreSQL, MongoDB, Redis, RabbitMQ, Docker Compose, k6, OpenTelemetry, Jaeger, Grafana, InfluxDB
- Bağlantılar
Problem
“Mikroservisler daha iyi ölçeklenir” sözü sürekli tekrarlanıyor, ama birebir karşılaştırılabilir bir sistem üzerinde nadiren ölçülüyor. Araştırma sorum şuydu: Aynı uygulamanın ortak backend’i, asenkron mesajlaşan bağımsız servislere bölündüğünde gerçekte ne değişir?
Ne yaptım
Aynı e-ticaret uygulamasını — hesaplar, katalog, sepet, siparişler, yorumlar, öneriler ve yapay zekâ destekli içerik — iki kez geliştirdim: bir Node.js monoliti olarak ve olay güdümlü bir mikroservis sistemi olarak (API gateway, ayrı alan servisleri, RabbitMQ olayları, Redis ve LLM bağımlılığı için gateway’de bir circuit breaker).
Ardından ikisini eşleştirilmiş senaryolarla k6 ile yük testine soktum, istekleri OpenTelemetry ve Jaeger ile servisler arasında izledim ve circuit breaker’ın davranışını görmek için hata enjekte ettim (Pumba ile LLM servisine 5 saniyelik gecikme).
Sonuç
500 sanal kullanıcıya kadar kademeli artan bir stres testinde mikroservis sürümü ortalama gecikmeyi 67,5 ms’de, p95’i 156,7 ms’de tuttu; monolitte bu değerler 262,4 ms ve 985,3 ms’ydi. Buna karşılık ham işlem hacminde monolit öndeydi (saniyede 243,6’ya karşı 182,1 istek). Yazma ağırlıklı test daha nüanslı bir tablo ortaya koydu: Mikroservislerde maksimum gecikme yine daha yüksekti, yani tipik durumdaki kazanç yavaş uç değerleri ortadan kaldırmadı.
Baştan sona koruduğum dürüst sonuç şu: Bunlar bu uygulamalara ve bu test koşularına ait gözlemler — veritabanı motorları ve yazma semantiği de farklı — evrensel bir sıralama değil. Tüm rakamlar repodaki kayıtlı JSON özetleri ve üretilmiş grafiklerle destekleniyor.