Wallet sistemi nasıl yapılır?

Arkadaşlar merhaba.
Yaklaşık 2 aydır kendime özel bir crm ve cms sistemi kodluyorum. Şu anda ödeme sistemine bir de bakiye sistemi eklemek istedim fakat bir konuda muğlakta kaldım. Kullanıcıların güncel bakiyesini veritabanında direkt mi kaydetmeliyim yoksa bir fonksiyon ile loglardan işlem tutarlarını artı ve eksi olarak toplayıp o şekilde fronta mı yazdırmalıyım? Güvenlik açısından 1. yöntemde pek sıkıntı olabileceğini düşünmüyorum çünkü çok fazla kontrol oluşturdum. 2. yöntem ise işlem sayısı çok olduğu zaman veritabanını çok yorar ve gecikme olur diye düşünüyorum. 2-3 yıllık bir sistemde 2-3 yılın tüm verilerini toplayıp çıkarması fikri saçma geliyor.
Bu konuda tecrübesi olan arkadaşlar varsa fikir belirtirse memnun olurum.
Teşekkürler.

eminilhan dedi:

Arkadaşlar merhaba.
Yaklaşık 2 aydır kendime özel bir crm ve cms sistemi kodluyorum. Şu anda ödeme sistemine bir de bakiye sistemi eklemek istedim fakat bir konuda muğlakta kaldım. Kullanıcıların güncel bakiyesini veritabanında direkt mi kaydetmeliyim yoksa bir fonksiyon ile loglardan işlem tutarlarını artı ve eksi olarak toplayıp o şekilde fronta mı yazdırmalıyım? Güvenlik açısından 1. yöntemde pek sıkıntı olabileceğini düşünmüyorum çünkü çok fazla kontrol oluşturdum. 2. yöntem ise işlem sayısı çok olduğu zaman veritabanını çok yorar ve gecikme olur diye düşünüyorum. 2-3 yıllık bir sistemde 2-3 yılın tüm verilerini toplayıp çıkarması fikri saçma geliyor.
Bu konuda tecrübesi olan arkadaşlar varsa fikir belirtirse memnun olurum.
Teşekkürler.

Genişletmek için tıkla...

Her işlemin hesabını verebilmek adına her türlü transactionu kesinlikle tutmalısınız, hesap_id-işlem-tarih-miktar vb. gibi bir tablon illa ki olmalı. (x işlemi yapıldı-> eksi y tl bakiye; kullanıcı hesaba bakiye yüklemesi yaptı->artı z tl bakiye vb.) Bunu da istediği takdirde kullanıcıya listeleyebilecek bir endpoint eklemeniz lazım.

Hadi diyelim ki performans kaygınız var, cache benzeri bir amaçla çalışacak ikinci bir tablo oluşturursunuz, yani 1. tabloya her işlemi kaydederken bu dediğim 2. tabloya da hızlı erişim için güncel bakiyesini yazarsınız.

1. tablo
yükleme; 1000
x işlemi; -100
y işlemi; -50
yükleme; 500

2. tablo
0
1000
900
850
1350

gibi. Gösterimde 2. tablodan, döküm için 1. tablodan (başlangıç-bitiş tarihleri aralığında) veri çekersiniz.

Not: crm ve benzeri sistemler çok sayıda tablodan binlerce satır veriyi çekip, işleyip, hızlı bir şekilde verebilmesi gereken ürünlerdir. Bu bakiye hesap dökümü aslında oldukça basit bir işlem; eğer burada performans sorunu olabileceğini düşünüyorsanız projenin her yerinde performans sorunu olacağını da düşünebilirsiniz.

Teşekkürler cevap için.
Log işlemini dediğiniz şekilde zaten tutuyorum.
Sadece 4-5 yıl önce çalıştığımız bir projede (o sıralar ben sadece front çalışıyordum) backend kodlayan arkadaş sanki veritabanında sabit bir şekilde balance değeri tutunca açık olur vb. söyledi diye hatırladığım için şüpheye düştüm.
Bu şekilde devam edelim o halde.

Gerektiginde event sourcing yaparak saglama yapabilecegin sekilde transaction history tuttugun muddetce tek bir alanda balance degeri tutmanin guvenlik ya da mimari acidan bir sakincasi yok.

2nd level caching yapabilirsin DB ye sadece degisiklik varsa gidersin.
Ya da cok trafik varsa distribute eder, read ~ write DB lerini ayiririsin.

bitwise dedi:

Gerektiginde event sourcing yaparak saglama yapabilecegin sekilde transaction history tuttugun muddetce tek bir alanda balance degeri tutmanin guvenlik ya da mimari acidan bir sakincasi yok.

2nd level caching yapabilirsin DB ye sadece degisiklik varsa gidersin.
Ya da cok trafik varsa distribute eder, read ~ write DB lerini ayiririsin.

Genişletmek için tıkla...

Çok teşekkür ettim. Sağ olun.