VPS başına bir Redis çalıştırmak küçük-orta projelerde gayet makul bir karar. Sorun, birden çok uygulamanın 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üvenme

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 uygulanan 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 — bir kişi KEYS * koştuğunda 100k+ key’li bir instance’da event loop saniyelerce kilitleniyor. 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ı: bir prefix yazmak, yeni bir process başlatmaktan ucuzdur.