İlişkisel DB yok: Get/put deposunda kimlik doğrulama
Azure Table Storage gibi yalnızca get/put destekleyen bir depo üzerinde kimlik doğrulama sistemi kurmanın anahtar tasarımı ve eşzamanlılık desenleri.
Bir mühendislik ekibi, kullanıcılar, roller, oturumlar, OAuth izinleri ve refresh token'lar gibi ilişkisel görünen bir veri modeline sahip olmasına rağmen kimlik doğrulama sistemini Azure Table Storage üzerine kurmuş: join, ikincil indeks, artırma operatörü ve çok satırlı işlem sunmayan, sadece partition key ve row key tanıyan bir key-value deposu. Bu tercih maliyet ve operasyonel sadelik için yapılmış; connection pool yönetimi veya veritabanı ölçeklendirme derdi yok, ama karşılığında query planner olmadan çalışmak gerekiyor.
Çözüm, sorgu mantığını anahtar tasarımına gömmek üzerine kurulu: erişim örüntüleri baştan biliniyorsa (kullanıcıyı id ile getir, izinleri getir, kodu tüket gibi), partition ve row key'ler bu sorguları karşılayacak şekilde tasarlanabiliyor. Zaman damgasına göre filtreleme yerine, her yazma ve silme işlemini ayrı bir change-log tablosuna kaydederek tam tablo taramasını önleyen kendi CDC mekanizmalarını kurmuşlar. Eşzamanlılık ise ETag tabanlı koşullu yazma ve yeniden deneme döngüleriyle sağlanıyor; hesap kilitleme sayaçları, tek kullanımlık kod tüketimi ve lider seçimi gibi senaryolar bu optimistic concurrency deseniyle çözülüyor.
Bu yaklaşımın bedeli açık: ad-hoc sorgular, join'ler ve çok satırlı işlemlerden vazgeçiliyor, her invaryantın tek bir kayıt içinde yaşaması gerekiyor. Ancak kimlik doğrulama gibi erişim örüntüleri sabit ve öngörülebilir sistemler için bu takas mantıklı; hiç kullanılmayacak bir query planner'dan vazgeçilip neredeyse sıfır operasyonel yük olan bir depolama katmanı elde ediliyor. Mühendisler için mesaj net: veri modelinin ilişkisel görünmesi, veritabanının ilişkisel olması gerektiği anlamına gelmiyor.