Geçtiğimiz Ekim ayında Lizbon'da bir otel odasında, dört aydır üzerinde çalıştığım bir proje yönetim aracını demo öncesi test ederken, otelin Wi-Fi'ı bağlanıyor gibi görünüp hiçbir şey yüklemeyen o sinir bozucu durumu yaşadım. Uygulamamız boş bir ekran ve dönen bir yükleyici ile karşılaştı, ardından zaman aşımı hatası geldi. Telefonumdan hücresel veriye bağlandığımda ise her tıklama iki saniyelik bir bekleme anlamına geliyordu. O an, tüm bu altyapıya rağmen (React frontend, Node backend, Postgres veritabanı, Redis önbellek, GraphQL API) uygulamanın kendi verimi bile göstermek için 3000 mil uzaktaki bir sunucuya gitmesi gerektiğini fark ettim. İşte o gece, yerel-öncelikli (local-first) mimariyi ciddi ciddi araştırmaya başladım. Çünkü bir blog yazısı okuduğumdan değil, gerçekten utanç verici bir durumla karşılaştığım içindi.
Yerel-öncelikli mimariyi anlamak için önce ne olmadığını bilmek önemli: Offline-first (çevrimdışı-öncelikli) değil, sadece bir service worker eklemek de değil. Offline-first, ağ kesintilerini zarifçe yönetir ancak sunucu hâlâ tek doğruluk kaynağıdır. Yerel-öncelikli ise bir veri mimarisidir: Kullanıcının cihazı, verinin birincil kopyasını tutar. Uygulama yerel veritabanına yazıp okur, anında işlem yapar ve sunucuyla arka planda senkronize olur. Sunucu, varsa, bir senkronizasyon eşi olarak çalışır; kimlik doğrulama, yedekleme ve erişim kontrolü gibi özel yetkilere sahiptir ancak verinin kapı bekçisi değildir. Bu ayrım, tüm yığını değiştirir: İstemci, veriyi göstermek için izin isteyen ince bir görünüm değil, kendi veritabanına sahip dağıtık bir sistem düğümüdür.
Ancak her proje yerel-öncelikli mimariye uygun değildir. Sunucu tarafından üretilen veriler (analitik panoları, sosyal medya akışları, arama sonuçları) bu yaklaşım için kötü bir seçimdir. Güçlü işlemsel tutarlılık gerektiren bankacılık, ödeme işleme ve envanter yönetimi gibi sistemlerde de ACID garantileri olan tek bir otoriter veritabanı gerekir; nihai tutarlılık (eventual consistency) para kaybettirebilir. Ayrıca, çevrimdışı veya işbirliği ihtiyacı olmayan basit CRUD uygulamaları için de gereksiz bir karmaşıklıktır. Büyük veri kümeleri ise istemci cihazlara sığmayacağı için fiziksel olarak uygulanamaz.
Peki yerel-öncelikli mimari nerede parlar? Not alma uygulamaları, belge düzenleyiciler, işbirlikçi tasarım araçları, proje yönetimi, güvenilmez bağlantılara sahip saha uygulamaları, veri gizliliğinin satış noktası olduğu ürünler ve gerçek zamanlı işbirliği gerektiren her şey. Kısacası, anında etkileşimden faydalanan ve sunucu çökse bile hayatta kalması gereken kullanıcı tarafından oluşturulan veriler için idealdir. 2026'da bu mimariyi düşünüyorsanız, öncelikle projenizin gerçekten buna ihtiyacı olup olmadığını sorgulayın. Yanlış projeye yerel-öncelikli yaklaşımı zorlamak, altı haftanızı boşa harcamanıza neden olabilir; tıpkı bir iş arkadaşımın bana söylediği gibi: 'Veri sunucuda üretiliyor, istemciye kopyalanacak bir şey yok. Ne yapıyorsun?'
