Yanlış Bilet, Yanlış Çözüm: Mühendislikte İşin Bitmesiyle Problemin Bitmesi Arasındaki Fark

Bir kullanıcı uygulamada ödeme yaptığını gördü, ancak arka planda bakiyesi yetersiz kaldı. Üç ödeme girişi işlendi, bir sipariş oluşturuldu. Hiçbir bilet kapanmadı, ancak sistemde sorun vardı. Bu hikaye, mühendislik ekiplerinin en sık karşılaştığı başarısızlık biçimini gösteriyor: mükemmel çalışan sistemler yerine kullanıcıya ulaşmayan çözümler üretmek.

Bilet Odaklı Mühendislikten Sistem Odaklıya Geçiş

Erken kariyerindeki mühendisler genellikle "bilet odaklı" çalışır. Bir bilet atanır, kod yazılır, testler geçer, pull request gönderilir ve bilet kapatılır. Bu yaklaşım başlangıçta faydalıdır, ancak büyüdükçe bir handikap haline gelir.

Biletleri kapatan mühendis değerlidir, ancak "Bu bilet hangi gerçek problemi çözüyor ve doğru yerde mi çözülüyor?" sorusunu soran mühendis daha da önemlidir. İşte bu farkı gösteren bir örnek:

• Arka uç mühendisi ödeme uç noktasını geliştirir. Tüm statü kodlarını doğru döndürür, hata yönetimini eksiksiz yapar. Test kapsamı %100. Bilet kapatılır.
• Mobil geliştirici ödeme ekranını inşa eder. Uç noktaya çağrı yapar, yanıtı yönetir, kullanıcıya onay veya hata gösterir. Kullanıcı arayüzü pürüzsüz çalışır. Bilet kapatılır.

Ancak kimse şu soruya yanıt aramamıştır: Kullanıcı ödeme işlemi sırasında ağ bağlantısını kaybederse ne olur?

Arka uç: ödeme işlendi, hata yok. Mobil: zaman aşımı, "Ödeme başarısız oldu" mesajı gösterir. Kullanıcı yeniden deneyince çifte ödeme gerçekleşir. Her iki mühendis de kendi görevlerini kusursuz yerine getirmiştir. Ancak asıl iş problemi — kullanıcıyı bir kez şarj etmek ve güvenilir şekilde onaylamak — çözülmemiştir. Çünkü bu problem mühendislerin biletlerinin arasındaki boşlukta yer almıştı.

Gerçek Senaryo 1: Aynı Anda Başarılı ve Başarısız Olan Ödeme

Üretim ortamında bu durumdan daha sık bahsedildiğini biliyoruz. Ödeme akışı şöyledir: mobil başlatır → arka uç şarj eder → ödeme işlemcisi onaylar → arka uç yanıt verir → mobil kullanıcıya onay gösterir.

Her ok arasındaki ağ gecikmesi sisteme gizlice sızar. Eğer arka uç ödeme işlemcisinden onay aldıktan sonra mobil yanıt vermeden bağlantı koparsa, hem arka uç logları hem de ödeme işlemcisi logları başarılı olarak görülür. Mobil uygulama ise "Ödeme başarısız oldu. Lütfen tekrar deneyin." mesajını gösterir. Güvenilir bir uygulama olduğunu düşünen kullanıcı yeniden deneyince çifte ödeme gerçekleşir.

Bu sorunun çözümü sadece arka uçta veya sadece mobilde değil, sistemin tamamında yatıyor. Çözümün temel bileşeni idempotency anahtarlarıdır: mobil, her ödeme girişimi için benzersiz bir anahtar üretir ve her istekle birlikte gönderir. Arka uç bu anahtarı kullanarak aynı isteğin yeniden gönderilmesinin çifte şarj oluşturmasını engeller.

// Mobil: ödeme girişimi başına benzersiz anahtar oluştur ve sakla
const idempotencyKey = `pay_${userId}_${orderId}_${Date.now()}`;
localStorage.setItem('pending_payment_key', idempotencyKey);

// Her yeniden denemede aynı anahtarı gönder
const response = await fetch('/api/payments', {
  method: 'POST',
  headers: {
    'Idempotency-Key': idempotencyKey,
    'Content-Type': 'application/json'
  },
  body: JSON.stringify({ amount, currency, orderId })
});

// Arka uç: bu anahtarla daha önce başarılı ödeme var mı kontrol et
async function processPayment(req) {
  const idempotencyKey = req.headers['idempotency-key'];
  const existing = await db.payments.findOne({ idempotencyKey });
  
  if (existing?.status === 'success') {
    return existing; // Aynı sonucu geri gönder, tekrar şarj etme
  }
  
  const charge = await paymentProcessor.charge(req.body);
  await db.payments.create({ idempotencyKey, ...charge });
  return charge;
}

Bu çözümün var olabilmesi için arka uç ve mobil mühendislerinin birlikte oturup şu soruyu sormaları gerekirdi: Ağ başarısız olduğunda kullanıcı deneyimi nasıl görünüyor?而不是: Benim bileşenim çalışıyor mu?

İşte asıl fark burada yatıyor.

Gerçek Senaryo 2: "Çalışan" Akıllı Cihazın Gizli Sorunu

Bir ekip akıllı ev cihazı geliştiriyor: donanım, mobil uygulama ve bulut arka uç olmak üzere üç ayrı mühendislik dalı. Her ekip kendi biletini kapatıyor, ancak kullanıcı deneyimi bir bütün olarak ele alınmıyor.

• Donanım mühendisi cihazın durum değişikliklerini bulut API'sine doğru gönderen firmware geliştiriyor. Testler geçiyor, bilet kapatılıyor.
• Mobil mühendisi buluttan gelen durum değişikliklerini doğru şekilde alıp arayüzü güncelleyen uygulama geliştiriyor. Testler geçiyor, bilet kapatılıyor.
• Arka uç mühendisi donanımdan veri alan ve mobil uygulamaya ileten API geliştiriyor. Yük testi yapılıyor, bilet kapatılıyor.

Kullanıcılar cihazı satın alıyor. Işığı açmak için düğmeye basıyorlar. Işık ancak 11 saniye sonra yanıyor. Hiçbir sistemde hata yok. Gecikme üç bileşen arasında dağılmış durumda: her biri bireysel olarak sorunsuz çalışıyor, ancak her biri 3–4 saniyelik işlem ve sorgulama gecikmesi ekliyor. Kimse kullanıcının gerçekten yaşadığı sayıya — düğmeye basma ile ışığın yanması arasındaki süreye — odaklanmadı.

Ürün incelemeleri cihazı "gecikmeli" ve "tepki vermeyen" olarak tanımlıyor. Mühendislik ekibi kendi metriklerine baktığında ise hiçbir sorun bulamıyor.

Bu, güvenilirliğin bileşen özelliği olarak değil, sistem özelliği olarak görülmediğinde başımıza gelen durumdur.

Gerçek güvenilirlik — kullanıcıların yaşadığı güvenilirlik — sadece her katmanın kesişiminde var olur. Arka uç %99,9 kullanılabilirlikte olabilir. Ancak mobil SDK her 5 saniyede bir sorgulama yapıyorsa, kullanıcıya ulaşan yanıt süresi en iyi ihtimalle 5 saniyedir ve arka uç bile devreye girmeden önce. Donanım aktarım gecikmesi ve bulut-mobil push gecikmesi de buna eklenince sonuç ortaya çıkar.

Bunu yakalamanın tek yolu, bireysel bileşenlerin değil, tüm yolculuğun alet etmektir:

// Kullanıcı yolculuğunu uçtan uca ölçümle
// Sadece "API yanıt verdi mi?" değil, "Kullanıcı geri bildirim aldı mı?"
const journeyStart = performance.now();

await hardwareCommandAPI.send(deviceId, 'turn_on');
const userFeedbackTime = performance.now() - journeyStart;

console.log(`Kullanıcı ışığı açmak için bekledi: ${userFeedbackTime}ms`);

Bu sistemler inşa edilirken, mühendislerin sadece kendi biletlerine odaklanmamaları, tüm kullanıcı yolculuğunu sahiplenmeleri gerekiyor. Aksi takdirde, biletler kapatılırken kullanıcıların sorunları asla çözülmüyor.

Geleceğe bakıldığında, başarılı teknoloji ekiplerinin ortak özelliği sistem odaklı düşünmektir. Mühendisler artık sadece biletleri kapatmakla kalmayacak, kullanıcıların gerçekten ihtiyaç duydukları deneyimi sunmanın yollarını bulacaklar.