Rol & kapsam
Cookinglife (mutfak ürünleri satan, yanında fiziksel mağazaları da olan bir e-ticaret şirketi) tüm depo sürecini benim kurduğum ve o günden beri geliştirdiğim bir sistem üzerinde yürütüyor: sipariş alma, toplama (tekli, toplu, arabalı ve çok katmanlı), stok ve raf konumu yönetimi, paketleme, gönderi etiketleri ve ERP olarak NetSuite ile senkronizasyon. Sürekli bakımın yanında mevcut PHP platformu, kesinti olmadan modül modül Laravel'e taşınıyor.
- Sipariş alımından sevkiyata: tüm fulfilment süreci için tek bir sistem; siparişler ve stok için doğruluk kaynağı olarak NetSuite'e bağlı.
- Birden fazla toplama yöntemi (tekli, toplu, arabalı, çok katmanlı) ve sahada OnScan.js ile barkod okutma.
- Sendcloud üzerinden çok taşıyıcılı gönderi etiketleri; NetSuite "packed" durumundan sonra etiketi oluşturur oluşturmaz onu çeken kendi sweep görevimizle.
- Shopify ve Magento entegrasyonları, ayrıca Alumio üzerinden adres ve telefon numarası normalizasyonu.
- Kesintisiz Laravel göçü: modül modül (siparişler, toplama, stok, sevkiyat, NetSuite, yönetim) nginx yönlendirmesiyle, modül başına anında geri alma imkânıyla.
Etki
- Toplama, stok ve sevkiyat için ayrı araçlar yerine tüm fulfilment süreci için tek bir sistem.
- Kit siparişlerinde (birden fazla parçadan oluşan ürünler) görülen yapısal NetSuite hatası, her şeyin tek rafta olmasını beklemek yerine stoğu otomatik olarak birden fazla rafa tahsis ederek çözüldü.
- Gönderi etiketlerinin oluşturulması ile çekilmesi arasındaki yarış durumu, tekrar eden bir senkronizasyon göreviyle ortadan kaldırıldı; böylece etiketler arada bir kaybolmayı bıraktı.
- WMS mesai dışında çöktüğünde devreye giren yedek bir sevkiyat yolu; siparişlerin toplama kuyruğunda iki kez görünmemesi için mutabakat mantığıyla birlikte.
- Yaklaşık iki yıldır kesintisiz üretimde (Ağustos 2024'ten bu yana 848 commit) — sıfırdan bir proje değil, şirketle birlikte büyümeyi sürdüren bir sistem.
Mimari
Üç katman: paylaşılan bir Core, TailorFitWMS modülünün kendisi ve müşteri bazlı Overwrites — böylece şirkete özgü uyarlamalar çekirdeğe sızmaz. İşlevsellik, şirket bazında açılıp kapatılabilen eklenti modülleri olarak kurgulanmış, olay tabanlı genişletme noktalarıyla. Veriler MySQL (işlemsel veriler), MongoDB (belgeler) ve Redis'te (önbellek ve oturumlar) tutuluyor; arka plan işleri (etiket senkronizasyonu, NetSuite görevleri) Laravel Horizon üzerinden, saatte 100 ila 500 iş hızında çalışıyor. Mevcut PHP platformunun Laravel'e devam eden göçü, nginx location bloklarıyla modül modül yapılıyor; böylece her parça geri kalanına dokunmadan ayrı ayrı yayına alınıp geri çekilebiliyor.
Model seçimi
Bu platformun merkezinde yapay zekâ/LLM yok — fulfilment mantığı (stok, toplama, sevkiyat, ERP senkronizasyonu) bir dil modelinin esnekliğini değil, öngörülebilirliği ve izlenebilirliği gerektirir. Buradaki asıl "model seçimi" yapay zekâ değil mimari: mevcut özel PHP çatısından daha geniş bir araç ekosistemi ve daha iyi sürdürülebilirlik için Laravel'e geçmek — ama bunu tek seferlik bir yeniden yazım yerine kademeli ve modül modül yaparak, 7/24 bir depoyu yöneten bir sistemdeki riski sınırlamak için.
Maliyet & gecikme
- Üretim ortamı, her birine 8 CPU / 8 GB ayrılmış 5 Docker servisinde çalışıyor — yalnızca yoğunluk anlarına değil, sürekli sipariş ve NetSuite trafiği işleyen bir sisteme uygun bir boyutlandırma.
- Gönderi etiketleri bilinçli olarak asenkron: NetSuite etiketi ancak "packed" durumundan sonra oluşturuyor, dolayısıyla sistemin beklemesi gerekmiyor — bir sweep görevi, sipariş sipariş sorgulamak yerine etiketleri her 3 dakikada bir topluyor.
- NetSuite entegrasyonu (OAuth1 TBA, SOAP + RESTlet + REST) zincirin daha yavaş halkası; tarama ve toplama gibi yerel depo işlemleri bundan bağımsız çalışmaya devam ediyor.
Çıkarılan dersler
Kit siparişleri (birden fazla parçadan oluşan ürünler) NetSuite'in VALID_LINE_ITEM_REQD hatasına takılıp kalıyordu; çünkü parçaların stoğu birden fazla rafa dağılmışken NetSuite satır başına tek raf bekliyordu. RESTlet entegrasyonu, stoğu otomatik olarak birden fazla rafa tahsis edecek şekilde yeniden yazılarak çözüldü. Gönderi etiketleri, NetSuite'in etiketi oluşturduğu an ile sistemin onu çektiği an arasındaki yarış durumu yüzünden arada bir kayboluyordu; her 3 dakikada bir çalışan tekrarlı bir sweep görevi bunu tek seferlik bir yama yerine yapısal olarak çözdü. WMS'in kendisinin çöktüğü akşamlar ve hafta sonları içinse sevkiyatın sürmesini sağlayan harici bir acil durum yolu var — sistem tekrar açıldığında aynı siparişlerin toplama kuyruğunda iki kez belirmesini önleyen mutabakat mantığıyla birlikte.