Physical Address
304 North Cardinal St.
Dorchester Center, MA 02124
Stripe’ın Veri Katmanı: DocDB Nedir?
Stripe, verilerini doğrudan MongoDB kullanarak değil, onun üzerine kendi veri katmanını kurarak yönetiyor. Bu katmanın adı DocDB.
Bu sistem saniyede milyonlarca sorguyu kaldırabilecek şekilde tasarlanmış.
Şimdi şöyle düşün:
MongoDB bir motor, ama Stripe bu motorun üstüne kendi arabasını yapıyor. Yani direksiyon, fren, güvenlik sistemleri hepsi onların kontrolünde.
Peki neden bunu yapıyorlar?
Çünkü bazı kritik ihtiyaçları var:
- Sürekli çalışır sistem (availability)
- Veri kaybı olmaması (durability)
- Yüksek performans
- Multi-tenant yapı (bir müşterinin yükü diğerini etkilemesin)
- Güvenlik ve yetkilendirme
Az Özellik = Daha Güvenli Sistem
Stripe ilginç bir karar alıyor: MongoDB’nin tüm özelliklerini açmıyor.
Yani şöyle düşün:
Elinde çok güçlü bir araba var ama maksimum hızı sınırlıyorsun.
Neden?
Çünkü fazla özellik = yanlış kullanım riski.
Bu yaklaşım “self harm avoidance” dediğimiz şey.
Yani sistemin kendi kendini bozmasını engellemek.
Proxy Katmanı: Her Şeyin Merkezi
Stripe’da client’lar (uygulamalar) veritabanına direkt bağlanmıyor.
Arada bir katman var: Database Proxy
Şimdi şöyle düşün:
Restorana girdin. Mutfakla direkt konuşmuyorsun. Garson var.
- Sen → Garson → Mutfak
- Mutfak → Garson → Sen
Bu proxy katmanı:
- Hangi verinin hangi sunucuda olduğunu bilir
- Trafiği doğru yere yönlendirir
- Kim ne kadar istek atabilir kontrol eder
- Güvenliği sağlar
Bu sayede sistem:
- Daha esnek olur
- Daha kolay ölçeklenir
- Client tarafı basit kalır
Sharding ve Chunk Mantığı
Veri tek bir yerde durmuyor, parçalara bölünüyor.
Bu parçalara “chunk” deniyor.
Yani şöyle düşün:
Büyük bir Excel dosyasını 100 parçaya böldün ve farklı bilgisayarlara dağıttın.
Ama bir problem var:
“Hangi veri hangi makinada?”
İşte burada devreye chunk metadata service giriyor.
Bu servis şunu tutar:
👉 Bu veri → şu shard’da
Proxy de bu bilgiye bakarak isteği doğru yere yollar.
Logical DB vs Physical Shard
Stripe burada çok kritik bir abstraction kullanıyor.
Veriyi direkt shard’a koymuyor, önce “logical database” oluşturuyor.
Yani şöyle düşün:
- Fiziksel sunucular = evler
- Logical DB = odalar
Artık taşıma işlemi şöyle oluyor:
❌ Tek tek eşyaları taşı
✅ Odayı komple taşı
Bu ne sağlıyor?
- Veri taşıma kolaylaşıyor
- Hot shard problemi azalıyor
- Büyük veri hareketleri daha hızlı oluyor
Asıl Zor Problem: Veri Taşıma (Migration)
Şimdi en kritik yere geldik.
Bir veriyi bir shard’dan diğerine taşıyorsun.
Ama sistem çalışmaya devam ediyor.
Bu neden zor?
Çünkü:
- Veri değişmeye devam ediyor
- Kullanıcılar işlem yapıyor
- Sistem duramaz
Stripe’ın Veri Taşıma Adımları
Bu süreci sadeleştirerek anlatalım.
1. Taşıma Kararı
Hangi veri hangi shard’dan nereye gidecek belirlenir.
2. Bulk Copy (Toplu Kopyalama)
Verinin snapshot’ı alınır ve yeni yere kopyalanır.
Ama burada önemli bir detay var:
Offset pagination kullanılmaz.
Onun yerine cursor kullanılır.
Yani şöyle düşün:
Kitapta sayfa sayfa atlamak yerine, kaldığın yerden devam ediyorsun.
Bu çok daha hızlıdır.
3. CDC (Change Data Capture)
Veri taşınırken eski shard hala yazı alıyor.
Peki yeni shard nasıl güncel kalıyor?
Cevap: CDC
- MongoDB oplog → Kafka → yeni shard
Yani şöyle düşün:
Yeni eve taşındın ama eski evine hala mektup geliyor.
Birisi o mektupları alıp sana getiriyor.
4. Consistency Check
Veri doğru taşındı mı?
Bu aşamada:
- Eksik veri var mı?
- Hatalı veri var mı?
kontrol edilir.
Bu adım kritik.
5. Trafik Switch (En Kritik Nokta)
Artık veri yeni shard’da hazır.
Ama kullanıcılar hala eski shard’a gidiyor.
İşte burada olay kopuyor.
Config Değişimi: Nasıl Herkes Aynı Anda Öğreniyor?
Binlerce proxy var.
Hepsine “artık buraya gitme, şuraya git” demek zor.
Stripe bunun için çok akıllı bir çözüm kullanıyor:
👉 Versioning sistemi
Version Trick: Çok Basit Ama Çok Güçlü
Her shard’ın bir version’ı var.
Şimdi şöyle düşün:
- Eski sistem → version 1
- Yeni sistem → version 2
Proxy eski bilgiyi biliyor (v1).
Ne oluyor?
- Proxy eski shard’a istek atıyor (v1 ile)
- Shard diyor ki:
❌ “Ben artık v2’yim, bu request eski” - Hata dönüyor (5xx)
- Proxy diyor ki:
👉 “Aaa config değişmiş” - Yeni route’u çekiyor
- Tekrar deniyor → doğru shard’a gidiyor
Kritik Trade-off
İlk request hata alıyor.
Ama sonrası düzgün çalışıyor.
Yani şöyle düşün:
- %100 senkron sistem ❌ (çok zor)
- İlk request fail + retry ✅ (pratik çözüm)
Bu mühendislikte klasik bir trade-off:
👉 “Mükemmel senkronizasyon yerine kontrollü hata + retry”
Özet
Stripe’ın yaptığı şey aslında çok net:
Veriyi taşırken sistemi durdurmamak.
Bunu sağlamak için:
- Proxy katmanı ile kontrolü merkezileştiriyor
- Veriyi chunk’lara bölüyor
- Logical abstraction ile taşıma kolaylaştırıyor
- CDC ile veri senkron tutuyor
- Versioning ile config değişimini yönetiyor
Sonuç?
👉 Sistem durmadan veri taşınabiliyor
👉 Kullanıcılar fark etmiyor
👉 Büyük ölçek sorunsuz yönetiliyor
Aslında bu çok basit:
Sistemi durdurmak yerine, hatayı tolere etmeyi öğreniyorsun.
Bu yazı How Stripe Scales MongoDB to 5 million Queries Per Second videosundan ilham alınarak yazılmıştır.
