Offline Çalışma Senaryosu: İnternet Kesilince Ne Yapılır?

Offline-First Mimari Nedir?

Bağlantı sorununu sahada değil, tasarım masasında çözmek

Geleneksel web ve mobil uygulamalar “online-first” mantığıyla çalışır: kullanıcı bir işlem yapar, sunucuya istek gider, yanıt döner, sonuç ekrana gelir. Bu modelin sessiz varsayımı şudur; internet her zaman vardır ve güvenilirdir. Sahada çalışan hiç kimse bu varsayımın doğru olmadığını size uzun uzun anlatmaya gerek duymaz.

Offline-first mimari ise varsayımı baştan tersine çevirir: uygulama, internet olmadan da temel işlerini yapabilecek şekilde kurgulanır. Bağlantı geldiğinde veriler arka planda sessizce senkronize edilir.

Offline-First’un Temel Prensipleri

• Local-first veri: Veriler önce yerel cihazda (telefon, tablet, yerel sunucu) saklanır
• Asenkron senkronizasyon: Bağlantı varken veriler arka planda merkeze iletilir
• Çakışma yönetimi: Aynı veri farklı noktalarda değişirse, önceden tanımlı kurallarla çözülür
• Progressive enhancement: Online iken ek özellikler devreye girer, offline iken çekirdek işlevler çalışmaya devam eder

Neden Offline-First?

Offline çalışma yalnızca internet kesintileri için değil, şu durumlarda da hızla kritik hale gelir:

• Düşük bant genişlikli bölgelerde çalışan saha ekipleri
• Yeraltında ya da metal yapılar içinde RF sinyali tutmayan depolar
• Uzak lokasyonlarda (şantiye, maden, tarım alanı) operasyon yapan ekipler
• Yurt dışında roaming maliyetini kısmak isteyen, seyahat eden personel
• Kesintisiz çalışmanın zorunlu olduğu üretim hatları

Sektör bazlı uygulamalara baktığınızda, özellikle üretim, lojistik ve perakendede offline yeteneklerin artık bir “iyi olsa güzel olur” konusu değil, doğrudan bir standart beklenti haline geldiğini görürsünüz.

Local Caching Stratejileri

Cache kararı, offline deneyimin belini tutan yer

Offline çalışmanın kalbi yerel veri saklamadır. Kullanıcının ihtiyaç duyacağı veri önceden inmiş olmalı, ürettiği işlem sonuçları da kaybolmadan güvenle saklanmalıdır. Bu iki cümle basit görünür ama uygulamada işin çoğu buradadır.

Browser Tabanlı Cache Seçenekleri

localStorage ve sessionStorage

Basit key-value depolama için uygundur. Sınırları belli: 5-10 MB kapasite, yalnızca string veri, senkron API. Yeri: kullanıcı tercihleri, son görülen öğeler, form taslakları.

IndexedDB

Büyük hacimli, yapılandırılmış veri için tasarlanmış bir NoSQL veritabanı. Yüzlerce MB kapasite, indeksleme ve sorgulama, asenkron API sunar. Ürün katalogları, müşteri listeleri ve offline işlem kuyruğu için doğru adres burasıdır.

Cache API (Service Worker)

HTTP yanıtlarını önbelleklemek için kullanılır. Statik dosyalar (HTML, CSS, JS, görseller) ve API yanıtları için biçilmiş kaftandır; PWA’ların temel taşıdır.

Mobil Uygulama Cache Seçenekleri

SQLite

Hem iOS hem Android’de native desteklenen ilişkisel veritabanı. SQL sorgu desteği, transaction garantisi, büyük veri setleri… Kurumsal mobil uygulamaların büyük çoğunluğu bunu kullanır, boşuna değil.

Realm Database

Mobil için optimize edilmiş bir nesne veritabanı. Hızlı okuma/yazma, reaktif sorgular ve otomatik senkronizasyon desteği sunar. Özellikle real-time uygulamalarda tercih edilir.

Core Data (iOS) / Room (Android)

Platforma özel ORM katmanları. Artısı platform entegrasyonu, bellek yönetimi ve migration desteği. Eksisi ise cross-platform kod paylaşımını zorlaştırması.

Cache Stratejileri

• Cache-first: Önce cache’e bak, yoksa network’e git. Offline öncelikli uygulamalar için ideal.
• Network-first: Önce network’e git, olmazsa cache’e dön. Güncel veri önemliyse tercih edilir.
• Stale-while-revalidate: Cache’den hemen döndür, arka planda tazele. Hız ile güncelliği ortalar.
• Cache-only: Sadece cache’den döndür. Statik içerik için uygun.
• Network-only: Sadece network’ten al. Gerçek zamanlı veri için.

Senkronizasyon Mekanizmaları

Senkronizasyon doğru kurulmazsa, veri bütünlüğü ilk kurban olur

Offline senaryonun en kritik parçası, yerelde biriken değişikliklerin merkeze nasıl aktarılacağıdır. Senkronizasyon, bir yandan veri bütünlüğünü koruyacak, diğer yandan kullanıcıyı bekletip deneyimi bozmayacaktır. İnce ayar tam da burada başlar.

Senkronizasyon Modelleri

Full Sync (Tam Senkronizasyon)

Her senkronizasyonda tüm veri seti karşılaştırılır. Artısı basitlik; eksisi, büyük veri setlerinde yavaşlaması ve bant genişliğini yemesi. Küçük veri setleri ve nadiren değişen master data için uygundur.

Delta Sync (Fark Senkronizasyonu)

Yalnızca son senkronizasyondan bu yana değişen kayıtlar aktarılır. Takip, timestamp ya da versiyon numarası üzerinden yapılır. Kurumsal uygulamalarda fiilen standart yaklaşım budur.

Event Sourcing

Verinin son hali yerine olaylar (events) senkronize edilir; merkez sunucu bu olayları sırayla uygulayarak güncel durumu yeniden inşa eder. Çakışma çözümünü kolaylaştırır ve size hazır bir audit trail verir. Karşılığında implementasyonu karmaşıktır.

Senkronizasyon Tetikleyicileri

• Bağlantı geri geldiğinde: Network durumu dinlenir, online olunca otomatik başlar
• Periyodik: Belirli aralıklarla (örneğin her 5 dakikada) kontrol edilir
• Kullanıcı tetikli: Manuel “senkronize et” butonuyla başlatılır
• İşlem bazlı: Kritik işlemlerden hemen sonra senkronizasyon denenir
• Background sync: Service Worker ile arka planda, uygulama kapalıyken bile çalışır

Kuyruk Yönetimi

Offline yapılan işlemler bir kuyrukta bekler. Bu kuyruğu yönetirken gözden kaçırılmaması gerekenler:

• Sıralama: İşlemlerin doğru sıraya konması (önce müşteri oluştur, sonra sipariş gir)
• Retry mantığı: Başarısız işlemlerin tekrar denenmesi, exponential backoff
• Idempotency: Aynı işlemin birden fazla gönderilmesinin zarar vermemesi
• Timeout: Çok eski işlemlerin iptali ya da uyarıya dönüşmesi

Conflict Resolution Yöntemleri

Çakışma olacak; mesele hangi kuralla çözüldüğü

Birden fazla kullanıcı ya da cihaz aynı veriyi offline düzenleyebilir. Bağlantı gelip herkes eş zamanlı senkronize olmaya çalıştığında bu değişiklikler çakışır. Conflict resolution, işte bu çakışmaların nasıl çözüleceğini önceden belirler.

Otomatik Çözüm Stratejileri

Last-Write-Wins (LWW)

En son yapılan değişiklik kazanır. Uygulaması kolaydır ama veri kaybı riski taşır. Yeri: kritik olmayan veriler, log kayıtları, tercih ayarları.

First-Write-Wins (FWW)

İlk yapılan değişiklik geçerli olur, sonrakiler reddedilir. Yeri: önce gelenin kazandığı senaryolar; tipik örnek stok rezervasyonudur.

Merge (Birleştirme)

Her iki değişiklik de korunur ve birleştirilir. Field-level merge ile farklı alanlardaki değişiklikler otomatik olarak yan yana durur. Yeri: doküman işbirliği, listeye ekleme işlemleri.

Version Vectors / CRDT

Conflict-free Replicated Data Types, matematiksel olarak çakışmasız birleştirme garantisi verir. Otomatik ve tutarlı bir sonuç sunar; karşılığında her veri tipine oturmaz ve implementasyonu karmaşıktır.

Manuel Çözüm Gerektiren Durumlar

Bazı çakışmalar otomatik çözülemez; kullanıcının araya girmesi gerekir:

• Aynı alana farklı değerlerin yazılması (örneğin iki farklı fiyat girişi)
• İş kurallarının ihlal edildiği durumlar (örneğin stoktan fazla satış)
• Kritik finansal ya da yasal sonucu olan değişiklikler

Conflict Prevention

En iyi çakışma çözümü, çakışmayı en baştan engellemektir:

• Pessimistic locking: Kayıt düzenlenirken başkası düzenleyemez (online gerektirir)
• Optimistic locking: Kayıt versiyon numarasıyla kontrol edilir
• Partition by user: Her kullanıcı yalnızca kendi verisini düzenler (çakışma ihtimali yok)
• Append-only: Veri güncellenmez, yeni kayıt eklenir (log yaklaşımı)

Mobil Uygulamalarda Offline Mod

Offline çalışmanın en görünür sahnesi mobil

Saha ekipleri, teslimat personeli, satış temsilcileri, teknik servis… hepsi mobil cihazla çalışır. Bu kullanıcılar için offline çalışma lüks değil, doğrudan iş sürekliliği demektir.

Native vs Hybrid vs PWA

Native Mobil Uygulama

Artıları: tam donanım erişimi, en iyi performans, gelişmiş offline yetenekler. Eksileri: iOS/Android’i ayrı geliştirme, mağaza onay süreci, güncelleme dağıtımı derdi.

Hybrid Uygulama (React Native, Flutter)

Artıları: tek kod tabanı, native’e yakın performans, olgun bir offline plugin ekosistemi. Eksileri: native kadar esnek olmaması, bazı platform özelliklerine sınırlı erişim.

Progressive Web App (PWA)

Artıları: kurulum gerektirmez, otomatik güncellenir, cross-platform çalışır. Eksileri: sınırlı donanım erişimi, iOS’ta kısıtlı Service Worker desteği ve büyük veri setlerinde performans sıkıntısı.

Offline Mobil Uygulama Özellikleri

• Background sync: Uygulama arka plandayken senkronizasyon
• Push notification queue: Offline iken gelen bildirimlerin kuyruklanması
• Selective sync: Yalnızca ihtiyaç duyulan verinin seçilerek indirilmesi
• Bandwidth-aware sync: Bağlantı türüne göre (WiFi/mobil veri) değişen senkronizasyon davranışı
• Offline indicator: Bağlantı durumunun kullanıcıya net gösterilmesi
• Pending operations display: Bekleyen işlemlerin listesi ve durumu

Mobil Offline Best Practices

• Kritik verileri önceden indirin (pre-cache)
• Büyük dosyaları (resim, PDF) lazy-load yapın
• Offline işlem limitlerini belirleyin ve kullanıcıya bildirin
• Pil tüketimini optimize edin (sync sıklığı, arka plan aktivitesi)
• Depolama kullanımını izleyin ve eski verileri temizleyin

Edge Computing ve Yerel İşlem

İşlemi merkeze taşımak yerine, verinin yanına götürmek

Edge computing, veri işlemlerini merkezi bulut yerine kullanıcıya yakın noktalarda yapar. Offline senaryoda edge node’lar, internet gitmiş olsa bile yerel operasyonu ayakta tutan düğümlerdir.

Edge Node Türleri

On-Premise Mini Server

Fabrika, depo ya da mağaza içine konumlanan küçük bir sunucu. Yerel ağda çalışır; internet kesildiğinde yerel işlerin tamamını sürdürür, bağlantı gelince merkeze senkronize olur.

IoT Gateway

Sensör ve makinelerden veri toplayan, ön işleme yapan cihaz. Offline durumda veriyi yerelde biriktirir, bağlantı gelince yığın halinde gönderir. Üretim ve lojistik ortamlarında sık görülür.

Thick Client

Kullanıcının çalışma istasyonunda çalışan, kapsamlı iş mantığı barındıran uygulama. Browser tabanlı thin client’in aksine offline’da tam işlevsellik sunar. ERP masaüstü istemcileri bu kategoridedir.

Edge Computing Avantajları

• Düşük latency: Verinin merkeze gidip gelmesi gerekmez
• Bant genişliği optimizasyonu: Merkeze yalnızca özet/aggregated veri gider
• Offline dayanıklılık: İnternet olmadan da çalışabilme
• Veri mahremiyeti: Hassas veri yerelde kalabilir
• Regülasyon uyumu: Bazı verilerin ülke/bölge dışına çıkamaması gerekliliği

Edge-Cloud Hibrit Mimari

Modern offline mimarisi, edge ile cloud’u birbirine bağlar:

• Edge katmanı: Gerçek zamanlı işlemler, yerel cache, offline yetenek
• Cloud katmanı: Merkezi veri deposu, analitik, raporlama, yedekleme
• Sync katmanı: Edge ile cloud arasında güvenilir veri aktarımı

Sahadan Örnek: Dağıtım Firmasının Offline Dönüşümü

Offline Senaryoda En Sık Yapılan 7 Hata

1. Offline Durumu Test Etmemek

Geliştirme ve test ortamlarında internet hep açıktır. Gerçek offline durum simüle edilmeden canlıya alınan uygulamalar sahada tökezler. Chrome DevTools’un “Offline” modu tek başına yeterli değildir; işi gerçek cihazda görmeniz gerekir.

2. Sınırsız Offline Süre Varsaymak

Sistem 1 saat offline çalışabilir, peki 1 hafta offline kalırsa? Biriken veri hacmi, stale data riski ve senkronizasyon karmaşıklığı önceden hesaplanmalı. Makul bir offline süre limiti koymadan yola çıkmayın.

3. Conflict Resolution Planlamamak

“Çakışma olursa bakarız” yaklaşımı. Çakışma senaryoları tasarım aşamasında belirlenmeli, her veri tipi için çözüm stratejisi yazıya dökülmeli. Yoksa kullanıcı bir gün tutarsız veriyle yüz yüze gelir.

4. Kullanıcıya Bilgi Vermemek

Kullanıcı offline çalıştığını bilmiyor, işlemlerinin beklemede olduğunu görmüyor. Net bir offline indicator ve pending operations gösterimi şart. Belirsizlik, doğrudan güven kaybına yol açar.

5. Tüm Verileri İndirmeye Çalışmak

100.000 ürün, 50.000 müşteri… hepsini mobil cihaza indirmek hem gereksiz hem imkânsız. Selective sync ile kullanıcının gerçekten ihtiyaç duyduğu veri seti belirlenmeli. Aksi halde depolama ve performans birlikte çöker.

6. Senkronizasyon Hata Yönetimi Eksikliği

Sync başarısız olursa ne olacak? Retry mantığı, hata loglama, kullanıcı bildirimi ve manuel müdahale seçeneği planlanmalı. “Sessizce başarısız olan” bir senkronizasyon, en sinsi veri kaybı sebebidir.

7. Güvenlik İhmali

Offline saklanan veri şifreli mi? Cihaz kaybolur ya da çalınırsa ne olur? Yerel veritabanı şifrelemesi, secure storage ve remote wipe yeteneği offline uygulamalarda pazarlık konusu değildir.

İyi planlama, offline senaryoda veri kaybının önündeki en sağlam bariyer

Offline Çalışma Başarı Metrikleri

Aşağıdaki metrikler, offline çalışma senaryosunun başarısını ölçmek için işe yarar (değerler temsilidir):

Offline Hazırlık Kontrol Listesi (16+ Madde)

Sıkça Sorulan Sorular (SSS)