Ana içeriğe geç

Authority Cache

Bu sayfa, authority:{authority_id} key ailesinin Qapu içindeki işletim sözleşmesini tanımlar.

Bu key ailesi, tekil authority kaydını hızlı çözmek için kullanılır. Device authz projection zincirindeki temel entity cache katmanlarından biridir.

Doküman Seti​

  • Genel omurga ve kullanım mantığı: bu sayfa
  • Kanonik payload, owner ve invalidation sözleşmesi: ilerleyen doküman sprintinde ayrı contract sayfasına taşınacaktır
  • Okuma, invalidate ve rebuild akışı: bu sayfada özetlenir

Key Pattern​

  • authority:{authority_id}

Örnek:

  • authority:88

Owner Service​

  • Primary writer: authority yöneten servis
  • Primary readers: API, auth middleware, projection builder
  • Secondary writer: read-through rebuild yapan servisler

Authoritative Source​

  • authorities

Temel İlke​

  • Bu key authority entity kaydının cache/projection kopyasıdır.
  • Owner, active, user/device ilişkisi gibi authz için kritik alanların hızlı çözülmesini sağlar.
  • DB authoritative katmandır, Redis ise hızlı lookup katmanıdır.

Kanonik Yapı​

{
  "authority_id": 88,
  "user_id": 123,
  "device_id": "46000000C47CA670",
  "owner": true,
  "is_active": true,
  "updated_at": "2026-04-20T06:00:00Z"
}

Read / Write Paths​

Read Path​

  1. authority:{authority_id} Redis'ten okunur.
  2. Hit varsa entity alanları doğrudan kullanılır.
  3. Miss varsa authorities tablosundan rebuild edilir.

Write Path​

  1. Authority DB'de oluşturulur, güncellenir veya pasiflenir.
  2. Commit sonrası key invalidate edilir veya güncel gövde ile overwrite edilir.
  3. Sonraki read path gerekirse key'i yeniden kurar.

Write Order​

  1. authorities authoritative kaynaktır.
  2. Redis cache DB commit'inden önce güncellenmez.
  3. Primary strateji invalidate + rebuild veya güvenli overwrite yaklaşımıdır.
  4. Amaç stale authority kaydının authz zincirine sızmamasıdır.

Failure ve Drift Senaryoları​

Senaryo A: Redis miss​

  • Beklenen davranış: DB fallback + write-back
  • Etki: ilk lookup maliyeti artar, sonrası hızlanır

Senaryo B: Authority stale​

  • Beklenen davranış: invalidate + rebuild
  • Etki: owner/active değişimi yanlış authz üretmez

Senaryo C: Authority pasif ama cache kaldı​

  • Beklenen davranış: pasifleştirme akışında invalidate zorunludur
  • Etki: pasif authority ile işlem yapılması önlenir

Rebuild​

Rebuild kaynakları:

  • authorities

Rebuild adımları:

  1. authority kaydı DB'den okunur
  2. minimal authz için gereken alanlar normalize edilir
  3. SETEX authority:{authority_id} ile yazılır

Gözlemlenebilirlik Metrikleri​

  • authority_cache_hit_ratio
  • authority_cache_miss_total
  • authority_cache_rebuild_total
  • authority_cache_invalidation_total
  • authority_cache_db_fallback_latency_ms

TTL ve Invalidation​

  • TTL: 5m - 15m

Invalidation tetikleri:

  1. authority owner flag değişirse
  2. authority active flag değişirse
  3. authority device/user ilişkisi değişirse
  4. authority silinirse veya pasiflenirse

Çapraz Referanslar​

  • /projects/qapu/services/redis/keyspace/authority-permissions-cache
  • /projects/qapu/services/redis/keyspace/device-user-authz
  • /projects/qapu/services/api/jwt-auth-flow