VPS başına bir Redis çalıştırmak küçük-orta projelerde gayet makul bir karar. Sorun, birden çok uygulama aynı instance’ı paylaşmaya başladığında ortaya çıkıyor: bir projenin users anahtarı diğerinin users anahtarını eziyor, biri FLUSHALL çağırınca herkes çuvallıyor.

Çözüm yeni bir Redis kurmak değil; namespace disiplini.

Üç katmanlı bir anahtar şeması

Üretimde şu kalıbı kullanıyorum:

<env>:<app>:<bounded-context>:<key>

Örnek:

prod:billing:invoice:42
prod:auth:session:1c2f...
staging:notify:queue:retry

Bu üçlüye sahip olmak iki şeyi getiriyor:

  1. Aramada netlik. redis-cli --scan --pattern 'prod:billing:*' ile sadece bir projenin anahtarlarını görebiliyorum.
  2. Yanlışlıkla silmeyi zorlaştırma. FLUSHDB yerine redis-cli --scan --pattern 'staging:*' | xargs redis-cli DEL yazarken iki kez düşünüyorum.

Logical DB’lere güvenmeyin

Redis’in 0-15 arası logical DB’leri var ama tek kelimeyle: kullanmayın. Üç sebep:

  • SELECT komutu sadece o bağlantı için scope’lu — connection pool’da kaos.
  • Bazı kütüphaneler MULTI/EXEC blokları içinde DB switch’i desteklemiyor.
  • Redis Cluster logical DB’leri zaten desteklemiyor; yarın cluster’a geçerseniz tüm varsayımınız çöker.

Namespace prefix’i öğrenip uygulamak tek yöntemdir.

Connection-level izolasyon

Laravel kullanıyorsanız config/database.php içinde her uygulama için ayrı bir Redis bağlantısı tanımlayın ve prefix ile namespace’i bağlantıya gömün:

'redis' => [
    'billing' => [
        'host' => env('REDIS_HOST'),
        'password' => env('REDIS_PASSWORD'),
        'port' => env('REDIS_PORT', 6379),
        'database' => 0,
        'prefix' => 'prod:billing:',
    ],
    'auth' => [
        // ...
        'prefix' => 'prod:auth:',
    ],
],

Artık Redis::connection('billing')->set('invoice:42', ...) çağrısı otomatik olarak prod:billing:invoice:42 yazıyor. Geliştirici yanlışlıkla namespace yazmayı unutursa bile sistem kendini koruyor.

Tehlikeli komutları kapatın

redis.conf içinde production’da şu komutları yeniden adlandırmak veya kapatmak iyi bir fikir:

rename-command FLUSHDB ""
rename-command FLUSHALL ""
rename-command KEYS ""

KEYS özellikle önemli — tarama boyunca event loop’u bloke ediyor ve diğer tüm istemciler sırada bekliyor. Redis’in kendi dokümantasyonu 1 milyon anahtarlı bir veritabanını giriş seviyesi bir dizüstünde yaklaşık 40 ms’de tarıyor, yani 100k key’li bir instance’da milisaniyeler mertebesindesiniz — ama maliyet anahtar sayısıyla birlikte büyüyor, milyonlarca anahtarlı instance’larda duraklama canınızı yakacak kadar uzuyor. Yerine SCAN kullanılması zorunlu olmalı.

Ne zaman bu kalıbı bırakırsınız?

Üç sinyalden biri varsa ayrı Redis instance’larına geçin:

  1. Bir projenin trafiği diğerlerinin gecikmesini ölçülebilir biçimde etkiliyor.
  2. Bir proje persistent storage istiyor (RDB/AOF), diğerleri cache-only.
  3. Bir proje farklı bir Redis sürüm/feature ihtiyacı duyuyor.

Bunlardan önce şu basit kuralı aklınızda tutun: bir prefix yazmak, yeni bir process başlatmaktan ucuzdur.