---
title: 🚨 Bir refactor, cache hit rate’i %91’den %3’e düşürdü. Evet, sadece 1 değişiklik.
description: 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.
author: Burak Kaşıkcı
date: 2026-07-22
updated: 2026-07-23
tags:
  - clean code
  - refactoring
  - software development
  - performance optimization
  - cache
  - cache strategy
  - caching
  - api design
  - backend development
  - .net
  - csharp
  - software architecture
  - system design
  - performance
  - database
  - sql
  - production
  - scalability
  - coding best practices
  - yazılım
  - yazılım geliştirme
  - performans optimizasyonu
  - sistem tasarımı
  - clean architecture
  - backend
  - api
  - cache yönetimi
  - refactor
  - yazılım mimarisi
canonical: https://burakkasikci.com/blog/bir-refactor-cache-hit-ratei-91den-3e-dusurdu-evet-sadece-1-degisiklik
slug: bir-refactor-cache-hit-ratei-91den-3e-dusurdu-evet-sadece-1-degisiklik
---

# 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ı:

```http
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.