Makale, bir iş görüşmesinde "yüksek derecede dayanıklı bir veritabanı tasarlayın" sorusu üzerine yaşanan bir deneyimi anlatıyor. Yazar, finans teknolojileri alanındaki tecrübesiyle, finansal işlemler için ACID uyumlu, otomatik yük devretme ve nokta-zamanında kurtarma özelliklerine sahip CloudNativePG tabanlı bir çözüm öneriyor. Ancak görüşmeci, bağlam belirtmeden sadece 'Cassandra' gibi genel bir yanıt beklediği için yazar mülakatı geçemiyor. Bu durum, veritabanı tasarımının ürünün özel ihtiyaçları ve kullanım senaryoları olmadan yapılamayacağı temel sorununu ortaya koyuyor. Yazar, "dayanıklı bir veritabanı tasarlayın" sorusunun aslında bir ürün sorusu olduğunu ve ürün hakkında bilgi sahibi olmadan doğru bir yanıt verilemeyeceğini vurguluyor. Bir veritabanının, bir sistemin yaşayan bir organı gibi olduğunu ve hangi "vücuda" yerleştirileceğinin bilinmesi gerektiğini belirtiyor. Cassandra gibi veritabanları, dağıtık sistemlerde büyük veri hacimlerini yönetme ve düğüm arızalarına karşı dayanıklılık sağlama konusunda mükemmel olsa da, finansal defterler gibi kesin tutarlılık (ACID) gerektiren senaryolar için uygun değildir. Makale, "eventual consistency" sunan Cassandra'nın, finansal işlemlerde kabul edilemez riskler taşıdığını açıklıyor. Finansal bir defterde tutarsızlık, sadece felsefi bir rahatsızlık değil, aynı zamanda mevzuat ihlali ve potansiyel dolandırıcılık riski anlamına gelir. Bu nedenle, veritabanı seçimi ve tasarımı, depolanacak verinin türü, sorgu kalıpları ve ürünün hayatta kalması gereken hata modları gibi kritik faktörlere göre yapılmalıdır. Genel bir "dayanıklı" tanımı, gerçek dünya ihtiyaçlarını karşılamaktan uzaktır.
Veritabanı tasarımı, ürünün özel ihtiyaçları ve kullanım senaryoları göz önünde bulundurularak yapılmalı, genel dayanıklılık beklentileriyle değil.