Kurumsal bir e-ticaret platformunu günde 1.000 hatadan çift haneye indirmek

Bağlam

Birkaç Avrupa pazarında satış yapan büyük bir optik perakende zinciri: numaralı cam, çerçeve, kontakt lens ve lens bakımı; yaklaşık 20.000 ürünlük bir katalog. Platform composable commerce yığınında çalışıyordu: kayıt sistemi olarak headless bir ticaret backend’i ve Symfony ile React üzerine kurulu, sepet, indirim ve ödeme gibi temel yetenekleri sağlayan bir SaaS ticaret frontend’i.

Sağlayıcı platformu, herhangi bir varsayılan sayfanın hem backend hem frontend tarafında ezilip yeniden yazılmasına izin veriyordu. Müşteri, giriş hariç neredeyse her yüzeyi özelleştirmişti.

Problem

Platform günde yaklaşık 1.000 hata kaydı ortalamasıyla çalışıyordu. Hepsi farklı değildi; tek bir kusur 150 kez loglayabiliyordu. Ama profil genişti: veri yoğun uçlarda performans çöküşü, yanlış sepet toplamları, hiç oluşmayan siparişler, borçlanılandan sapan ödeme tutarları ve en pahalı sınıf olan yanlış üretilen özel numaralı cam siparişleri.

Teşhisin sert bir kısıtı vardı: SaaS aboneliği yalnızca son altı ayın loglarını gösteriyordu; dolayısıyla her kök neden, tüm geçmiş değil kayan bir pencere içinde bulunmak zorundaydı.

Yaklaşım

Kademeli bir hata azaltma programı

Hataları yüzeye çıktıkça düzeltmek yerine, merkezi loglar ve APM izleriyle kök nedenleri izole ederek, çözülebilirlik ve etki alanı sırasına göre sınıf sınıf çalıştık:

• Temel kusurlar: kaynak kod hâlâ canlıysa düz başarısızlıklar denetlendi ve temizlendi; geri kalan her şeyi saklayan gürültü ortadan kalktı.
• Yarış koşulları: yanlış hesaplanan sepet toplamları ve ticaret backend’ine hiç ulaşmayan siparişleri üreten eşzamanlılık hataları giderildi.
• Zaman aşımları: aynı ürün kategorilerinde üst üste binen birden fazla indirim tanımına dayandığı bulundu; birleşen hesaplama isteği zaman aşımına düşürecek kadar uzuyordu.
• Üçüncü taraf dayanıklılığı: doğrudan kullanıcıya hata olarak yansıyan, yanıt vermeyen dış servislere karşı ödeme, arama ve sepete ekleme yolları sertleştirildi.
• Platformun kendi ürettiği yük: sağlayıcı platformun sunucu taraflı render ve önbellek ısınma sıçramalarının tetiklediği hatalar azaltıldı.

Ortak kök neden indirim motoruydu

Ticaret backend’i temel indirim yapıları sunuyor ama gerçek bir kural motoru sunmuyordu; bu yüzden promosyon mantığı uygulama koduna yazılmıştı. Tek bir kampanya şöyle okunabiliyordu: A ürünü için tanımlı indirimi al; müşteri daha önce X ürününü aldıysa ikincisini üstüne ekle; ama yaşam boyu harcaması bir eşiği geçtiyse ikisini de kaldır ve yerine üçüncüsünü uygula.

Bu, sürekli bir gidiş-dönüş zorunlu kılıyordu: tanımları çek, uygulama kodunda hesapla, sonucu özel indirim olarak geri yaz. Üstelik tüm hesaplama ürün sayfasında, sepette ve ödeme öncesinde yeniden yapılıyordu. Üç ila beş çakışan kampanya aktifken istekler doğrudan zaman aşımına düşüyordu.

Platformun yönetim panelini yönetilen bir indirim katmanına genişlettik: çakışmaları deterministik çözen açık bir öncelik listesi, kampanyaların kod değişikliği olmadan açılıp kapanmasını sağlayan aktif/pasif durum ve tekrarlı yeniden hesaplamayı ortadan kaldıran önbellek.

Bu tek iş, sepet yarış koşullarının, ödeme tutar tutarsızlıklarının ve zaman aşımlarının çoğunu çözdü. Platformun en yüksek etkili üç hata sınıfının üçü de aynı kontrolsüz hesaplama yoluna dayanıyordu.

Ödeme doğruluğu

Ödeme sağlayıcısı entegreydi ama tutar uyuşmazlıkları üretiyordu: üst üste binen indirim kuralları yarış koşulları ve hatalı öncelik sıralaması nedeniyle yanlış hesaplanıyor, tahsil edilen tutar borçlanılandan sapabiliyordu. Altta yatan hesaplama kusurlarını teşhis edip düzelttik; doğrudan finansal ve müşteri güveni sonuçları olan bir hata sınıfıydı.

Katmanlı önbellek

Sağlayıcı platform tam sayfa önbelleği sunuyor ama API katmanında hiçbir şey önbelleklemiyordu: ticaret backend’ine ve diğer üçüncü taraf servislere giden her backend isteği taze çıkıyordu. Varsayılan sayfalar kademeli olarak özel implementasyonlarla değiştirilirken Redis önbelleğini aşamalarla getirdik: kullanıcıdan bağımsız katalog yanıtları, sonra müşteri kapsamlı anahtarlar altında müşteriye özgü veriler, sonra tamamen render edilmiş kullanıcıya özgü sayfalar.

Numaralı cam sipariş bütünlüğü

En pahalı hata sınıfı bir hata değil, yapısaldı. Müşteri cam seçiyor, sipariş doğrudan geçiyor, otomatik bir üretim doğrulama sistemi onu asenkron alıyor ve başarısızlıkta durumunu değiştiriyordu. Üç problem birleşiyordu: bu durum değişikliği mağaza tarafına hiç geri yansımıyordu, müşteri yine de başarılı bir sipariş görüyordu; müşteriler yanlış girilmiş numarayı 5–10 dakika sonra fark ediyor ve araya girmenin yolu yoktu; ve fiziksel olarak imkânsız kombinasyonlar kabul ediliyordu; seçilen çerçeve için fazla kalın cam gerektirecek kadar yüksek bir numara bunlardan biriydi.

Sonuç: siparişler ya müşteri aksini sanırken sessizce hiç üretime girmiyor ya da yanlış üretilip geri dönüyordu.

Yerine geçecek mimariyi ve akışı biz önerdik, ekip uyguladı. Doğrudan sepete eklemenin yerini, yönlendirmeli adım adım bir yolculuk aldı: cam tipi, sonra her alanı gerçek bir reçete görseli üzerindeki konumuyla eşleyen ekran içi yönlendirmeyle numara girişi, sonra yalnızca o numarayla uyumlu çerçeveler, sonra sepet; gönderim öncesinde açık bir yeniden onay ile. Arkasında ise gecikmeli onay durum makinesi: siparişler yerleştirildiğinde onaylı gösterilmiyor; 10–15 dakikalık bir yerleşme penceresinden sonra üretim doğrulaması bir şey bildirmediyse sipariş onaylıya yükseltiliyor; müşteri de her iki sonuçta da e-postayla bilgilendiriliyor, tamamen eksik olan geri bildirim döngüsü kapanıyor.

Arama

Katalog arama birinci sınıf bir problemdi: en hızlı sorgular 10 saniye sürüyor, bazıları zaman aşımına düşüyordu. Ticaret backend’ini besleyen mevcut hattın küçük bir değişiklikle arama indeksini de besleyebileceği gözleminden yola çıkarak Algolia’ya geçişi önerdik: arama yükünü backend’den kaldırmak, gecikmeyi düşürmek ve benzer ürün önerilerini açmak. Uygulanabilirlik incelemesinden sonra sağlayıcı bunu kendi yol haritasına aldı ama müşteri beklemeyi reddetti. Tüm implementasyonu biz teslim ettik: indeks tasarımı, veri yapısı ve dışa aktarma hattı, React entegrasyonu ve aramanın sunucu tarafında da tüketilebilmesi için bir Symfony API katmanı.

Sonuç

• Günlük hata kaydı ~1.000’den çift haneye düştü.
• Paranın gerçekten risk altında olduğu yolda ödeme tutar uyuşmazlıkları ortadan kalktı.
• On dış servis çağrısı yapan istek yolları yaklaşık üçe indi.
• Katalog arama 10 saniye üstü ve zaman aşımından saniye altına geçti.
• Numaralı cam siparişleri artık sessizce kaybolamıyor ya da imkânsız bir spesifikasyona göre üretilemiyordu.
• Ne testi ne statik analizi olan bir kod tabanına linting getirildi; müşteri otomatik testi, manuel bir QA mühendisinin sistemi gerçek kullanıcı gibi denediği gerekçesiyle reddetmişti; dolayısıyla o kısıt içinde ulaşılabilir en güçlü kapı bir linter’dı.