Eş Zamanlı Stok Güncellemelerinde Yarış Durumlarını Tespit ve Çözme: Depoda Pratik Rehber

Giriş: Neden tek bir problem seçiyoruz?

Depo ve stok takip süreçlerinde karşılaşılan sorunlar çeşitlidir; bu yazıda tek odak noktamız eş zamanlı stok güncellemelerinden kaynaklanan yarış durumu (race condition) problemleri. Bu uzun kuyruklu, bilgi amaçlı sorgu; "Neden stok adetleri anlık olarak birbirini tutmuyor ve sistemde çakışma oluyor?" sorusuna teknik ve uygulanabilir yanıtlar getirmeyi amaçlıyor. Bayrak Bilişim’in barkod ve depo çözümlerine ilişkin daha fazla bilgi için barkod ve depo hizmetlerimiz sayfasına göz atabilirsiniz.

Problem tanımı ve tipik belirtiler

Yarış durumu, aynı stok satırı üzerinde birbirine paralel gerçekleşen işlemlerin birbirini geçersiz kılmasıyla ortaya çıkar. Depo ortamında bu genellikle şu semptomlarla belirginleşir:

• Çift sayılan veya eksiye düşen stok kayıtları.
• ERP ile depo sisteminde belirli ürünlerde periyodik uyuşmazlıklar.
• Toplu alım/pick işlemlerinde anlık farklı sonuçlar (aynı sipariş farklı ekranlarda farklı adet gösterir).
• Geçici düzeltmelerden (reconciliation) sonra tekrar ortaya çıkan hatalar.

Kök nedenler: nereden başlamak gerekir?

Yarış durumu tek bir sebepten değil, birden fazla katmanın etkileşimiyle oluşur. En sık karşılaşılan kök nedenler:

• Veritabanı düzeyinde zayıf işlem (transaction) yönetimi: Düşük izolasyon seviyeleri, kısa süreli kilitler veya eksik atomic operasyonlar.
• Uygulama katmanında optimistik/pessimistik uyumsuzluğu: ORM konfigürasyonları ile elle yazılan SQL arasındaki farklılıklar.
• Dağıtık sistemler ve mesaj tekrarları: Mesaj kuyruğundan gelen tekrarlı mesajlar veya üretimde aynı olayın birden çok kez işlenmesi.
• Offline cihazlar ve senkronizasyon gecikmeleri: Barkod okuyucu/handheld cihazların çevrim dışı çalışıp toplu senkronizasyon sırasında çakışma yaratması.
• UI yarışları: İki operatörün aynı ürünü aynı anda fişlemesi (reserve/pick işlemi yoksa).

Teşhis: Hızlı kontrol listesi ve veri toplama

Önce sorunun sınırlarını daraltın. Aşağıdaki adımlar hem hipotez oluşturmanızı hem de somut veri toplamanızı sağlar:

• Log ve audit verilerini toplayın: hangi kullanıcı/cihaz ne zaman hangi satırı güncelledi? Eğer audit yoksa hemen ekleyin.
• Veritabanı seviyesinde row-version veya timestamp kolonu kontrolü: conflict sıklığına bakın.
• İşlem (transaction) sürelerini ölçün: uzun süren transaction'lar kilitlenmelere neden olur.
• Kuyruk/messaging sistemi loglarını inceleyin: duplicate mesaj, requeue veya consumer crash kayıtları var mı?
• Offline cihazların senkronizasyon zamanlarını ve batch boyutlarını belirleyin.

Uygulanabilir düzeltmeler — veritabanı katmanı

Veritabanı tasarımı ve transaction yönetimi yarış durumlarını engellemede kritik rol oynar. SQL Server ve benzeri ortamlarda aşağıdaki yaklaşımlar işe yarar:

• Atomic operasyonlar: Stok miktarını bir SELECT+UPDATE sırasıyla değil, tek bir UPDATE ... WHERE ... koşullusu ile azaltın; örnek: UPDATE stok SET miktar = miktar - @adet WHERE urunId = @id AND miktar >= @adet. Affected rows kontrolü yaparak başarısız (0 row) durumunda işlem geri çevrilir.
• Satır versiyonlama (rowversion): EF Core gibi ORM'lerin concurrency token'ını kullanın; güncelleme öncesi versiyon kontrolü ile çakışmaları tespit edebilirsiniz.
• Uygun izolasyon seviyesi: Snapshot veya Serializable izolasyonları dikkatli kullanın; her zaman performans maliyeti vardır. Kısa transaction'lar tercih edin.
• Application lock ve sp kullanımı: SQL Server sp_getapplock/sp_releaseapplock ile kritik bölge kilitleme, küçük ölçekli kilitlemeler için kullanılabilir.

Uygulanabilir düzeltmeler — uygulama ve mimari katmanı

Veritabanı tek başına çözüm değil; uygulama seviyesinde de sağlam stratejiler gerekir:

• İdempotent operasyonlar: Her stok değişikliğini işlem id'si ile gönderin; tekrar eden mesajlar aynı id ile geldiğinde ikinci kez işlem yapmayın.
• Optimistic concurrency + retry: Update başarısız olduğunda kısa bir bekleme ve yeniden deneme (exponential backoff) stratejisi uygulayın. Bu, yüksek performans gerektiren sistemlerde tercih edilir.
• Pessimistic locking: Kritik rezervasyon senaryolarında (ör. pick sırasında ürün rezervasyonu) kısa süreli lock kullanarak diğer işlemleri engelleyin.
• Reservation modeli: Adet azaltma yerine önce rezervasyon (hold) yapın; pick tamamlandığında kesin düşüm. Bu, paralel pick çakışmalarını azaltır.
• Event-driven ve CQRS: Yazma (write) akışını tek servise yönlendirip sıraya almak ve okuma (read) tarafını ayrı tutmak, yarış durumlarını doğal olarak azaltır.

Mesajlaşma ve dağıtık süreçler

Birden çok sistem (handheld, otomasyon hattı, ERP entegrasyonu) aynı stoğu güncelliyorsa, mesajlaşma katmanında şu önlemleri alın:

• Exactly-once veya at-least-once ile idempotency: Fakerce exactly-once garanti etmek zordur; bunun yerine at-least-once + idempotency en pratik yoldur.
• Sıralama ve sequence numaraları: Aynı ürün için gelen olaylara sequence numarası ekleyin; eski bir olayı işlemek ya da tekrar işlemek kolayca reddedilebilir.
• Deduplication store: İşlenen mesaj ID'lerini kısa süreli saklayarak tekrar işlemeyi önleyin.

Offline cihazlar ve batch senkronizasyonu

El terminalleri offline çalışma veya zayıf bağlantı durumlarında toplu senkronizasyon yapıyorsa şu pratikleri uygulayın:

• Her offline işlem için lokalde bir işlem ID'si ve timestamp tutun.
• Senkronizasyon sırasında gelen batch'leri küçük parçalara bölün ve her parçayı işlem id'siyle işleyin.
• Konflikt durumlarında önceki kayıtla merge/compensate mantığı uygulayın: örneğin aynı kayıttan hem çıkan hem giren hareket varsa işlem sırasına göre hesap yapılmalı.

Test etme: simülasyon ve yük testleri

Yaptığınız değişikliklerin etkili olduğunu doğrulamak için aşağıyı uygulayın:

• Çoklu paralel API çağrılarıyla load test: aynı ürün için eşzamanlı 100+ isteği simüle edin.
• Offline → online senkronizasyon senaryoları: birden çok cihazın aynı anda senkronize olduğu durumları test edin.
• Kaotik testler (chaos testing): beklenmedik consumer crash, mesaj duplicate veya ağ gecikmesi koşullarında sistem davranışını inceleyin.

İzleme ve operasyonel metrikler

Sorun tekrar etmesin istiyorsanız izlenebilirlik şarttır. Önerilen metrikler:

• Concurrency conflict oranı (günlük/haftalık).
• Reconciliation sayısı ve düzeltilen adet.
• Batch senkronizasyon hataları ve ortalama gecikme süreleri.
• İşlem başarısızlıkları (0 affected rows) ve retry sayısı.

Uygulama örneği: Basit bir atomic rezervasyon akışı (konsept)

Örneğin pick sırasında kullanabileceğiniz basit adımlar:

• API çağrısı ile Reserve isteği gönderilir (adet, ürünId, requestId).
• Veritabanında tek bir UPDATE ile rezervasyon uygulanır: UPDATE stok SET rezerve = rezerve + @adet WHERE urunId=@id AND miktar - rezerve >= @adet.
• DB affected rows == 1 ise rezervasyon başarılı, 0 ise başarısız (yetersiz stok ya da çakışma).
• Pick tamamlandığında Commit: miktar = miktar - @adet; rezerve = rezerve - @adet. Bu iki adımı transaction içinde yapın.

Karar vericilere kısa rehber: Hangi yöntemi seçmeliyim?

• Basit işlemler, düşük concurrency: Optimistic concurrency + retry yeterli olabilir.
• Yüksek hacim, kritik rezervasyon (örn. paketleme/pick hatları): Reservation modeli + küçük pessimist kilit/queue önerilir.
• Dağıtık sistemler ve çok sayıda entegrasyon: Event-driven + idempotency + deduplication mekanizmaları tercih edin.

Uygulamaya geçiş ve risk yönetimi

Değişiklikleri doğrudan üretime almadan önce aşamalı rollout planlayın:

• Önce staging ortamında load test ve üretim benzeri verilerle canary deployment yapın.
• Monitoring ile küçük bir bölümde (ör. %5 trafiğe) yeni davranışı izleyin.
• Reconciliation süreçlerinizi otomatikleştirerek geriye dönük hataları hızlıca düzeltin.

Sonuç ve izlenecek adımlar

Depoda eş zamanlı stok güncellemelerinden kaynaklanan tutarsızlıklar, veri tutarlılığına zarar verir ve operasyonel maliyet yaratır. Çözüm tek bir sihirli ayar değil; veritabanı, uygulama, cihaz ve mesajlaşma katmanlarının birlikte ele alınması gerekir. Özetle izlenecek yol:

• Audit ve loglama ile sorunu görünür kılın.
• Atomic ve idempotent operasyonları önceliklendirin.
• Reservation modeli, optimistic concurrency ve gerektiğinde pessimist kilitlemeyi kombinleyin.
• Event-driven yaklaşımlarda idempotency, sequence ve deduplication uygulayın.
• Test, canary ve izleme ile güvenli geçiş sağlayın.

Eğer bu konuyla ilgili mevcut sisteminizin analizi, performans testi veya özel yazılım çözümü gerekiyorsa bize ulaşabilirsiniz: iletişim. Bayrak Bilişim olarak C#, ASP.NET Core, SQL Server ve ERP entegrasyonlarında deneyimli ekiplerimizle uygulanabilir teknik yaklaşımlar sunarız.

Not: Bu rehber, uygulamaya dair yaklaşımlar ve mimari seçimler hakkında bilgi amaçlıdır. Her depo ortamı farklıdır; somut değişiklikleri uygulamadan önce yedekleme, test ve küçük çaplı pilot uygulamalar yapmanız önerilir.