03.f796270b numaralı fikir

🚨 Bir refactor, cache hit rate’i %91’den %3’e düşürdü. Evet, sadece 1 değişiklik..

Production'da masum görünen bir refactor, cache stratejisini bozarak performansı ciddi şekilde düşürebilir. Her kod tekrarı kötü değildir; bazıları bilinçli optimizasyonun parçasıdır.

🚨 Bir refactor, cache hit rate’i %91’den %3’e düşürdü. Evet, sadece 1 değişiklik.

Clean Code Her Zaman Daha Hızlı Kod Demek Değildir

Bir sistemde "küçük bir temizlik" yapılıyordu.

Ama o küçük temizlik, production ortamında hiç beklemediğimiz bir problemi tetikledi.


Hikâye Nasıl Başladı?

API'de iki farklı endpoint vardı:

GET /products/99      → 8 ms
GET /products?id=99   → 340 ms

İkisi de aynı veriyi döndürüyordu.

Bir junior geliştirici doğal olarak şunu düşündü:

"Bunlar duplicate. Temizleyelim."

Mantıklıydı. Hatta ilk bakışta tam bir best practice gibi görünüyordu.

Refactor yapıldı.

İki endpoint tek endpoint altında birleştirildi.


Sonuç: Sessiz Bir Performans Felaketi

Deploy sonrasında ilk metrikler gelmeye başladı.

  • Cache hit rate: %91 → %3
  • Latency: ciddi şekilde arttı
  • Database yükü: beklenmedik seviyede yükseldi
  • Infrastructure maliyeti: arttı

Sistem artık daha "temiz" görünüyordu.

Ama kesinlikle daha hızlı değildi.


Peki Ne Kırıldı?

Sorun kodda değildi.

Sorun, yapılan varsayımdı.

İki endpoint aynı veriyi döndürmesine rağmen sistem onları farklı şekilde kullanıyordu.

Çünkü:

  • Cache key'leri farklıydı.
  • Query string bazlı cache ayrımı bulunuyordu.
  • /products/99 ile /products?id=99 farklı cache entry'leri oluşturuyordu.

Yani sistem aslında şunu yapıyordu:

  • Bir istek doğrudan cache'den karşılanıyordu.
  • Diğer istek ise veritabanına gidiyordu.

Refactor sonrasında ise:

  • İki davranış tek noktada birleşti.
  • Cache partition bozuldu.
  • Cache etkinliği dramatik şekilde düştü.

Asıl Problem Neydi?

Biz yalnızca duplicate endpoint gördük.

Fakat sistem aslında farklı cache stratejileri kullanarak performans optimizasyonu yapıyordu.

Biz bunu fark etmeden kaldırmış olduk.


Çıkarılacak Ders

"Clean Code" her zaman doğru hedef olmayabilir.

Çünkü:

  • Her duplication kötü değildir.
  • Bazı tekrarlar bilinçli performans optimizasyonudur.
  • Yalnızca görünüşe bakarak refactor yapmak risklidir.

Refactor Yapmadan Önce Sorulması Gereken Sorular

Kodun neden öyle yazıldığını anlamadan yapılan temizlik bazen faydadan çok zarar getirebilir.

Refactor öncesinde kendine şu soruları sormakta fayda var:

  • Cache key davranışı değişiyor mu?
  • Query normalization uygulanıyor mu?
  • Database yükü artabilir mi?
  • Bu duplication gerçekten gereksiz mi, yoksa stratejik bir karar mı?

Bazen en temiz görünen kod, en doğru çalışan kod olmayabilir.

Bu bilgiler yeterli gelmediyse yapay zekaya sorabiliriz.