Pak eko saya ada kasus dimana 1 user bisa request sampai ratusan TPS di karenakan service saya merupakan payment agregator, masalahnya saya memiliki bottleneck di database dimana row lock users balance ini menjadi lambat ketika menghadapi high tps, sebelumnya saya sudah melakukan research dan pengetesan merubah alurnya untuk source of truth balance tidak lagi menggunakan user.balance, tapi pakai legder sum(amount) = saldo akhir.
saya gunakan saldo akhir di ledger lalu saya masukan ke redis kemudian pembacaan/validasi saldo di lakukan melalui redis user.balance.{userId}.
Masalahnya ada ketika redis mati cache akan hilang maka transaksi selanjutnya akan melakukan sum(amount) lalu masukan kembali data ke redis. proses sum(amount) ini sangat mahal dan lambat kalau transaksi peak. saya belum coba redis mode AOF tapi setelah saya tanya AI saya membutuhkan source of truth lain selain ledger, tapi masalahnya update dengan row lock itu sangat lambat ketika 1 user melakukan banyak transaksi.
kira-kira bagaimana cara menghandle proses pemotongan dan pengolahan saldo ini ya ketika high tps dan concurrency.
oh ia saya pakai tech stack berikut:
- Java
- RabbitMQ
- Redis
- PostgreSQL
Pak eko saya ada kasus dimana 1 user bisa request sampai ratusan TPS di karenakan service saya merupakan payment agregator, masalahnya saya memiliki bottleneck di database dimana row lock users balance ini menjadi lambat ketika menghadapi high tps, sebelumnya saya sudah melakukan research dan pengetesan merubah alurnya untuk source of truth balance tidak lagi menggunakan user.balance, tapi pakai legder sum(amount) = saldo akhir.
saya gunakan saldo akhir di ledger lalu saya masukan ke redis kemudian pembacaan/validasi saldo di lakukan melalui redis user.balance.{userId}.
Masalahnya ada ketika redis mati cache akan hilang maka transaksi selanjutnya akan melakukan sum(amount) lalu masukan kembali data ke redis. proses sum(amount) ini sangat mahal dan lambat kalau transaksi peak. saya belum coba redis mode AOF tapi setelah saya tanya AI saya membutuhkan source of truth lain selain ledger, tapi masalahnya update dengan row lock itu sangat lambat ketika 1 user melakukan banyak transaksi.
kira-kira bagaimana cara menghandle proses pemotongan dan pengolahan saldo ini ya ketika high tps dan concurrency.
oh ia saya pakai tech stack berikut: