Ürün 6 dk okuma Buğra Han Öksüz

BetterCAD'de Multiplayer Nasıl Çalışır? CRDT ile Eşzamanlı CAD

İki mimar aynı paftaya, aynı anda dokunabilmeli — kimse beklemesin, kimsenin işi diğerinin üstüne yazılmasın, bağlantı kopsa kaldığı yerden devam etsin. BetterCAD'in en zor mühendislik kararı buydu. Nasıl çözdüğümüze dair notlar.

Sorun: aynı paftaya iki kişi

Bir mimari ofiste tek bir parsel üstünde üç kişinin çalışması istisna değil: biri vaziyet planı, biri zemin kat, biri çatı. Geleneksel CAD yazılımlarında her biri ayrı bir .dwg dosyası açar, sonra birleştirme + manuel çakışma çözümü turu yapılır. Bu, 1990'ların workflow'u. Google Docs 2006'dan beri "aynı belgeye birden fazla kişi" deneyimini ortaya koydu. Figma 2016'da bunu tasarım yazılımlarına taşıdı. CAD hâlâ "dosya kilidi" çağında yaşıyor.

BetterCAD'i başlatırken vereceğimiz kararların en önemlilerinden biri buydu: multiplayer ilk gün, sonradan eklenen bir özellik değil, mimarinin temeli.

Neden klasik server-locking çözmez?

"Dosyayı kilitle, açan tek kişi" yaklaşımı (file locking) kabul edilemez UX. "Son yazan kazanır" (last-write-wins) bilgi kaybeder. "Operational Transform" (Google Docs'un kullandığı eski yaklaşım) işliyor ama her concurrent operasyon için merkezi server gerektiriyor — server düşse sistem durur.

Bize gerekli olan: offline çalışabilmek, çakışmasız birleşmek, server bağımlılığı minimum. Bu üç özelliği aynı anda veren tek matematiksel yaklaşım var: CRDT.

CRDT nedir?

CRDT (Conflict-free Replicated Data Type), distributed systems literatüründen gelen bir veri yapısı sınıfı. Temel garantisi şu: aynı veri üstünde N farklı node aynı anda değişiklik yapabilir; tüm operasyonlar herkese ulaştığında — sıra önemli olmaksızın — herkes aynı sonuca varır.

Bunu mümkün kılan iki matematiksel özellik:

  • Commutativity: operasyonların sırası önemsiz. A + B = B + A.
  • Idempotency: aynı operasyonu iki kez uygulamak tek kez uygulamaktan farklı sonuç vermez.

Pratikte: User A "duvar AB'nin uzunluğunu 10m yap" diyor, User B aynı anda "duvar AB'nin uzunluğunu 12m yap" diyor. İki operasyon da timestamp + node ID ile etiketleniyor. Tüm clientler her iki operasyonu da alıyor, aynı deterministik sıraya sokuyor (örn. timestamp tiebreaker), sonuç: duvar 12m. Kimsenin yazma denemesi kaybolmadı, kimse kilitlenmedi, "siz şu an düzenleyemezsiniz" pop-up'ı yok.

BetterCAD'in eşzamanlı mimarisi

     ┌─────────┐     WebSocket    ┌─────────┐    WebSocket    ┌─────────┐
     │ Client1 │ ◄───────────────► │  Sync   │ ◄─────────────► │ ClientN │
     │ (CRDT)  │                   │  Hub    │                 │ (CRDT)  │
     └─────────┘                   └─────────┘                 └─────────┘
          ▲                             │                            ▲
          │                       ┌─────────┐                        │
          └── IndexedDB           │Persist  │            IndexedDB ──┘
            (offline cache)       │ (DB)    │            (offline cache)
                                  └─────────┘
  • Her client kendi CRDT state'ini tutar (IndexedDB'de tarayıcı içinde cache)
  • Her çizim değişikliği küçük bir "operation" olarak WebSocket üstünden Sync Hub'a gönderilir
  • Hub operation'ları persist eder ve diğer client'lara broadcast eder
  • Bağlantı kopsa client offline çizmeye devam eder; geri geldiğinde missed operation'ları replay eder

Kullanıcının hissettiği şey

  • "Save" tuşu yok — yazdığın an local'de + sunucuda persist edilir.
  • Offline-first — internet koparsa çizim devam eder; bağlantı dönünce kendiliğinden senkronlanır.
  • Çoklu imleç — Figma deneyimi: kim nerede çiziyor canlı görünür.
  • Kişisel Undo — herkesin kendi Ctrl+Z geçmişi vardır; başkasının çizimini yanlışlıkla geri almazsın.
  • Çakışma pop-up'ı yok — "siz şu an düzenleyemezsiniz" diye bir dialog yoktur.
Bir önemli edge case CRDT konflikti deterministik çözer ama user intent'i her zaman koruyamaz. A duvarı sildi, B aynı anda duvarın uzunluğunu değiştirdi → final state: duvar silindi, B'nin uzunluk değişikliği "yetim" operasyon olur. BetterCAD bu durumlarda UX katmanında küçük bir uyarı gösterir ("Bu işlem başka bir kullanıcı tarafından silinen bir nesneye uygulandı").

Neden Türk imar mevzuatı sahnesinde kritik?

Türk mimari ofislerinde standart bir akış: parsel etüdü → vaziyet planı → kat planları → cephe → kesit → onay. Her aşamada farklı kişiler çalışır. Geleneksel CAD'lerde versiyonlama kâbus: kim hangi sürümü editliyor, hangi cephe son onaylı, biri parselasyonu değiştirince diğerlerinin işi mi gitti?

BetterCAD'de tek pafta — herkes kendi katmanında, herkesin görüş alanı canlı, çakışma yok. Bunun bir mimari ofise sağladığı kazanç, salt zamandan tasarrufun ötesinde: iletişim hatalarının %80'i ortadan kalkıyor (Figma'nın tasarım takımlarına yaptığı şeyin aynısı).

Limitler ve henüz çözmediklerimiz

  • Operation log uzun zamanda büyür — periyodik garbage collection (snapshot + log truncation) gerekir.
  • Vector clock overhead — her operasyon ek metadata taşır, net trafikte %5-10 artış.
  • Çok büyük paftalarda (10.000+ nesne) initial sync süresi hâlâ optimizasyon konusu — lazy load + partial sync üstünde çalışıyoruz.
  • Permissions modeli — kim hangi katmanı görür/editler, henüz basit (read/write); fine-grained access control yol haritasında.

Sonuç

CAD'de eşzamanlı çoklu kullanıcı 2026'da artık bir teknoloji sorunu değil, bir ürün kararı. Figma 2016'da tasarım yazılımı sektörünü nasıl alt-üst ettiyse, CRDT tabanlı CAD'ler mimari yazılım sektörünü dönüştürecek. BetterCAD'i o dönüşümün Türkiye'deki başlangıç noktası olarak kuruyoruz.

Mimari ofis veya eğitim kurumu olarak BetterCAD'de eşzamanlı çizimi denemek istersen: hanbisan.com/projeler/bettercad üzerinden erken erişim talep edebilirsin.

Hanbisan Mühendislik Notları · 17 Mayıs 2026 ← Tüm yazılar

İletişim