Omnichannel Ticaret Motoru: Mimarinin Sırları

"Omnichannel (Çok Kanallı)", perakendeciliğin en fazla aşınan kelimelerinden biridir. Satıcılar bu kelimeyi web sitesini yansıtan bir mobil uygulamadan, her kanalın gerçek zamanlı olarak envanter, müşteri bağlamı ve fiyatlandırma mantığını paylaştığı tam birleşik bir ticaret deneyimine kadar her şeyi ifade etmek için kullanır.

Salefony'yi kurmak, omnichannel (çok kanallı)'ın veri ve altyapı katmanında tam olarak ne anlama geldiğini tanımlamamızı zorunlu kıldı — çünkü pazarlama tanımı ile mühendislik gerçekliği arasındaki fark, çoğu platformun başarısız olduğu yerdir.

Omnichannel (Çok Kanallı) Gerçekte Neyi Gerektirir

Gerçek omnichannel (çok kanallı) ticaretin pazarlık konusu olmayan üç özelliği vardır:

Birleşik envanter: Bir ürünün mevcut miktarı her yerde gerçek zamanlı olarak aynı sayıdır. 3 adet mevcutsa web, mobil, POS ve pazar yeri kanallarında mevcuttur — web'de 3, uygulamada 3, mağazada ayrı 3 değil.
Birleşik müşteri kimliği: Çevrimiçi satın alan, mağazada iade eden ve sohbet yoluyla destek ile iletişime geçen bir müşteri her sisteme göre aynı kişidir. Tam etkileşim geçmişi her temas noktasında mevcuttur.
Tutarlı fiyatlandırma ve promosyonlar: Web'de aktif bir promosyon, açıkça hariç tutulmadıkça her yerde aktiftir. Kanallar arasındaki fiyat tutarsızlıkları destek yükü ve marka güveni sorunudur.

Çoğu omnichannel platformu bunlardan bir veya ikisini başarır. Üçünü birden başarmak veri modelini sıfırdan yeniden düşünmemizi gerektirdi.

Envanter Sorunu: Neden Zordur

Envanter yönetimi, her gün perakendede yaşanan şu senaryoları hesaba katana kadar basit görünür:

Bir müşteri ürünü çevrimiçi sepete ekler (rezerve edilmiş) başka bir müşteri mağazadan alır (satıldı). Hangi satış tamamlanır?
Bir depo çalışanı 5 ürünü hasar görür. Sistem bunu bir sonraki toplu senkronizasyondan önce yansıtmalıdır.
500 birim stoğu olan bir ürün için anlık kampanya 10.000 eş zamanlı sepete ekleme isteği üretir.

Geleneksel envanter sistemleri, depo yönetim sistemi ile her kanal arasında dönemsel toplu senkronizasyon kullanır. Düşük ölçekte işe yarar. Yüksek ölçekte e-ticaretteki en zararlı hata modunu üretir: fazla satış.

Dağıtılmış rezervasyon modeli etrafında envanter yönetimi inşa ettik.

Her sepete ekleme, 15 dakikalık TTL ile yumuşak bir rezervasyon oluşturur. Rezervasyon mevcut envanteri anında azaltır — bir sonraki senkronizasyonda değil. Ödeme tamamlandığında yumuşak rezervasyon sabit bir tahsise dönüşür ve depo yerine getirmeyi tetikler. TTL ödeme olmadan sona ererse rezervasyon serbest bırakılır ve envanter yeniden kullanılabilir hale gelir.

Zor kısım, dağıtılmış tutarlılık sorunudur: 10.000 eş zamanlı sepetle, serileştirme darboğazı oluşturmadan iki sepetin aynı birimi rezerve etmesini önleyen bir koordinasyon mekanizmasına ihtiyacınız vardır.

Bunu, Redis tabanlı rezervasyon sayaçlarıyla birleştirilmiş envanter kaydı düzeyinde iyimser kilitleme ile çözdük. Redis sayacı hızlı azaltma kontrolünü sağlar; PostgreSQL, işlem sırasında çakışma tespiti ile yetkili kaydı sağlar. Bir çakışma oluşursa — son birim için iki eş zamanlı rezervasyon — biri başarılı olur ve diğeri "ürün artık mevcut değil" mesajının gösterilmesini tetikleyen yumuşak bir başarısızlık alır.

18 aylık üretim sürecinde fazla satış oranımız: 0 olay.

Müşteri Kimliği: Çapraz Kanal Grafiği

Kanallar arasında müşteri kimliği, teknoloji sorunu olarak gizlenmiş bir veri modelleme sorunudur.

Bir perakende markasıyla etkileşime giren müşterinin şunları olabilir: web sitesinde bir e-posta hesabı, misafir ödeme geçmişi, bir sadakat programı üyeliği (farklı e-posta ile), Google aracılığıyla sosyal oturum açma ve telefon numarasına bağlı mağaza içi satın alma geçmişi. Bunlar aynı kişidir. Bunları birbirine bağlamak önemsiz değildir.

Deterministik çıpalarla olasılıksal bir kimlik grafiği uyguladık.

Deterministik çıpalar: doğrulanmış e-posta adresleri, telefon numaraları, sadakat kimlikleri. Deterministik bir çıpayı paylaşan iki kayıt kesinlikle aynı kişidir ve otomatik olarak birleştirilir.

Olasılıksal sinyaller: aynı cihaz kimliği, aynı fatura adresi, benzer isim + posta kodu kombinasyonları. Bu sinyaller güven puanını yükseltir. Bir eşiğin üzerinde kayıtlar otomatik olarak birleştirilir. Altında manuel inceleme için işaretlenir.

Kimlik grafiği, müşteri kaydı veritabanına gömülü olmayan ayrı bir servis olarak çalışır. Her kanal kimlik olayları yayar; grafik servisi bunları çözer ve standart bir müşteri profili tutar. Diğer tüm servisler müşteri verilerini kanalına özgü tablolardan doğrudan değil grafik üzerinden sorgular.

Bu ayrım, yeni bir kanal eklemenin — yeni bir pazar yeri entegrasyonu, yeni bir POS sistemi, yeni bir sosyal ticaret özelliği — yalnızca kimlik olayı yayınının uygulanmasını gerektirdiği anlamına gelir. Çözüm mantığı merkezi kalır.

Fiyatlandırma Motoru: Karmaşıklık Olmadan Kurallar

Perakendede fiyatlandırma gerçekten karmaşıktır. Taban fiyatlar, promosyon fiyatları, paket fiyatları, sadakat kademe fiyatları, kanala özgü fiyatlar ve süreli teklifler vardır. Kombinasyonlar hızla çoğalır.

Önemli miktarda mimari karmaşıklıktan bizi kurtaran erken bir karar aldık: tüm fiyatlandırma kuralları kanaldan bağımsız olarak aynı motor üzerinde değerlendirilir.

Fiyatlandırma kuralı şöyle görünür:

EĞER müşteri.sadakatKademesi == "Altın"
VE ürün.kategorisi == "Elektronik"
VE kanal IN ["web", "mobil"]
VE mevcutZaman ARASINDA promosyonBaşlangıç VE promosyonBitiş
O ZAMAN fiyat = tabanFiyat * 0.85

Kurallar kod olarak değil veri olarak depolanır. Yeni bir promosyon eklemek yeni bir kural kaydı oluşturmak anlamına gelir, yeni kod dağıtmak değil. Fiyatlandırma motoru, belirli bir müşteri + ürün + kanal kombinasyonu için geçerli tüm kuralları değerlendirir ve en düşük uygun fiyatı döndürür.

Kanala özgü fiyatlar yalnızca başka bir kural koşuludur. Farklı kanallar için ayrı fiyatlandırma veritabanlarına ihtiyacımız yok — kanalı girdi olarak dikkate alan bir kural motoruna ihtiyacımız var.

Senkronizasyon Katmanı: Eski Sistemleri Bağlamak

Omnichannel (Çok Kanallı) kapasitesi inşa eden çoğu perakendeci sıfırdan başlamıyor. Mevcut ERP sistemleri, eski POS yazılımları ve gerçek zamanlı entegrasyon (integration) göz önünde bulundurulmadan inşa edilmiş köklü depo yönetim sistemleri var.

Salefony'nin senkronizasyon katmanı bu gerçeği webhook'lar, yoklama adaptörleri ve değişiklik verisi yakalama kombinasyonuyla ele alır.

API'lere sahip modern sistemler için: webhook'lar gerçek zamanlı olaylar sunar. Envanter güncellemeleri, sipariş tamamlamaları, iade işleme — hepsi bir webhook hattından geçer.

Gerçek zamanlı API'leri olmayan eski sistemler için: yapılandırılabilir aralıklarla (envanter için 30 saniye kadar düşük, ürün kataloğu güncellemeleri için 4 saate kadar yüksek) yoklama adaptörleri kullanıyoruz.

Doğrudan erişimli veritabanları için: Debezium aracılığıyla değişiklik verisi yakalama, eski uygulamada herhangi bir değişiklik gerektirmeden satır düzeyindeki değişiklikleri olay veri yolumuza aktarır.

Senkronizasyon katmanı tüm bunları birleşik bir olay modeli arkasında soyutlar. Omnichannel (Çok Kanallı) motoru bir envanter güncellemesinin webhook'tan mı, yoklama işleminden mi yoksa CDC akışından mı geldiğini bilmez ve umursamaz.

Üretim Rakamları

Salefony bugün şunları yönetiyor:

340 perakende müşteride 8,3 milyon SKU
Günlük 2,4 milyon sipariş satırı
47 kanal türü (web, mobil, 12 POS sistemi, 7 pazar yeri, 28 sosyal ticaret entegrasyonu)
100ms'nin altında envanter kullanılabilirlik kontrolleri (p99)
18 ay içinde 0 fazla satış olayı

Bizi buraya getiren mühendislik ilkeleri karmaşık değil: birleşik veri modelleri, olay odaklı tutarlılık ve kanalı mimari sınır yerine girdi değişkeni olarak ele almak.